* Re: [PATCH v4 2/3] thp: add HPAGE_PMD_* definitions for !CONFIG_TRANSPARENT_HUGEPAGE
From: Andrea Arcangeli @ 2012-03-21 22:58 UTC (permalink / raw)
To: Andrew Morton
Cc: Paul Gortmaker, Naoya Horiguchi, KAMEZAWA Hiroyuki,
Daisuke Nishimura, Hillf Danton, David Rientjes, linux-kernel,
linux-mm, linux-next
In-Reply-To: <20120321154721.3b8884bd.akpm@linux-foundation.org>
Hi,
On Wed, Mar 21, 2012 at 03:47:21PM -0700, Andrew Morton wrote:
> On Wed, 21 Mar 2012 18:07:41 -0400
> Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> > On Mon, Mar 12, 2012 at 6:30 PM, Naoya Horiguchi
> > <n-horiguchi@ah.jp.nec.com> wrote:
> > > These macros will be used in later patch, where all usage are expected
> > > to be optimized away without #ifdef CONFIG_TRANSPARENT_HUGEPAGE.
> > > But to detect unexpected usages, we convert existing BUG() to BUILD_BUG().
> >
> > Just a heads up that this showed up in linux-next today as the
> > cause of a new build failure for an ARM board:
> >
> > http://kisskb.ellerman.id.au/kisskb/buildresult/5930053/
>
> The internet started working again.
>
> mm/pgtable-generic.c: In function 'pmdp_clear_flush_young':
> mm/pgtable-generic.c:76: error: call to '__build_bug_failed' declared with attribute error: BUILD_BUG failed
>
> I guess we shouldn't be evaluating HPAGE_PMD_MASK at all if
> !CONFIG_TRANSPARENT_HUGEPAGE, so...
Yes. Either that or define __HAVE_ARCH_PMDP_CLEAR_YOUNG_FLUSH without
actually implementing the function to flush it away of the .text (is
it perhaps flushed away at vmlinux link time?). That
function never could be called by ARM. The BUG() is actually correct
even in the original position, just now it triggers at build time
because it doesn't know it can't be called.
>
> --- a/mm/pgtable-generic.c~thp-add-hpage_pmd_-definitions-for-config_transparent_hugepage-fix
> +++ a/mm/pgtable-generic.c
> @@ -70,10 +70,11 @@ int pmdp_clear_flush_young(struct vm_are
> unsigned long address, pmd_t *pmdp)
> {
> int young;
> -#ifndef CONFIG_TRANSPARENT_HUGEPAGE
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> + VM_BUG_ON(address & ~HPAGE_PMD_MASK);
> +#else
> BUG();
> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> - VM_BUG_ON(address & ~HPAGE_PMD_MASK);
> young = pmdp_test_and_clear_young(vma, address, pmdp);
> if (young)
> flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
> _
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4 2/3] thp: add HPAGE_PMD_* definitions for !CONFIG_TRANSPARENT_HUGEPAGE
From: Andrew Morton @ 2012-03-21 22:47 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Naoya Horiguchi, Andrea Arcangeli, KAMEZAWA Hiroyuki,
Daisuke Nishimura, Hillf Danton, David Rientjes, linux-kernel,
linux-mm, linux-next
In-Reply-To: <CAP=VYLoGSckJH+2GytZN0V0P3Uuv-PiVneKbFsVb5kQa3kcTCQ@mail.gmail.com>
On Wed, 21 Mar 2012 18:07:41 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> On Mon, Mar 12, 2012 at 6:30 PM, Naoya Horiguchi
> <n-horiguchi@ah.jp.nec.com> wrote:
> > These macros will be used in later patch, where all usage are expected
> > to be optimized away without #ifdef CONFIG_TRANSPARENT_HUGEPAGE.
> > But to detect unexpected usages, we convert existing BUG() to BUILD_BUG().
>
> Just a heads up that this showed up in linux-next today as the
> cause of a new build failure for an ARM board:
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/5930053/
The internet started working again.
mm/pgtable-generic.c: In function 'pmdp_clear_flush_young':
mm/pgtable-generic.c:76: error: call to '__build_bug_failed' declared with attribute error: BUILD_BUG failed
I guess we shouldn't be evaluating HPAGE_PMD_MASK at all if
!CONFIG_TRANSPARENT_HUGEPAGE, so...
--- a/mm/pgtable-generic.c~thp-add-hpage_pmd_-definitions-for-config_transparent_hugepage-fix
+++ a/mm/pgtable-generic.c
@@ -70,10 +70,11 @@ int pmdp_clear_flush_young(struct vm_are
unsigned long address, pmd_t *pmdp)
{
int young;
-#ifndef CONFIG_TRANSPARENT_HUGEPAGE
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ VM_BUG_ON(address & ~HPAGE_PMD_MASK);
+#else
BUG();
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
- VM_BUG_ON(address & ~HPAGE_PMD_MASK);
young = pmdp_test_and_clear_young(vma, address, pmdp);
if (young)
flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
_
^ permalink raw reply
* Re: [PATCH v4 2/3] thp: add HPAGE_PMD_* definitions for !CONFIG_TRANSPARENT_HUGEPAGE
From: Paul Gortmaker @ 2012-03-21 22:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Naoya Horiguchi, Andrea Arcangeli, KAMEZAWA Hiroyuki,
Daisuke Nishimura, Hillf Danton, David Rientjes, linux-kernel,
linux-mm, linux-next
In-Reply-To: <20120321151900.42234501.akpm@linux-foundation.org>
On 12-03-21 06:19 PM, Andrew Morton wrote:
> On Wed, 21 Mar 2012 18:07:41 -0400
> Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
>> On Mon, Mar 12, 2012 at 6:30 PM, Naoya Horiguchi
>> <n-horiguchi@ah.jp.nec.com> wrote:
>>> These macros will be used in later patch, where all usage are expected
>>> to be optimized away without #ifdef CONFIG_TRANSPARENT_HUGEPAGE.
>>> But to detect unexpected usages, we convert existing BUG() to BUILD_BUG().
>>
>> Just a heads up that this showed up in linux-next today as the
>> cause of a new build failure for an ARM board:
>
> Dammit.
>
>> http://kisskb.ellerman.id.au/kisskb/buildresult/5930053/
>
> Site is dead. What was failure, please?
Odd, I just reloaded the above link and it seems alive?
Anyway here is where it goes off the rails.
mm/pgtable-generic.c: In function 'pmdp_clear_flush_young':
mm/pgtable-generic.c:76:136: error: call to '__build_bug_failed' declared with attribute error: BUILD_BUG failed
make[2]: *** [mm/pgtable-generic.o] Error 1
Build was for ARM, tct_hammer_defconfig
Paul.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4 2/3] thp: add HPAGE_PMD_* definitions for !CONFIG_TRANSPARENT_HUGEPAGE
From: Andrew Morton @ 2012-03-21 22:19 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Naoya Horiguchi, Andrea Arcangeli, KAMEZAWA Hiroyuki,
Daisuke Nishimura, Hillf Danton, David Rientjes, linux-kernel,
linux-mm, linux-next
In-Reply-To: <CAP=VYLoGSckJH+2GytZN0V0P3Uuv-PiVneKbFsVb5kQa3kcTCQ@mail.gmail.com>
On Wed, 21 Mar 2012 18:07:41 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> On Mon, Mar 12, 2012 at 6:30 PM, Naoya Horiguchi
> <n-horiguchi@ah.jp.nec.com> wrote:
> > These macros will be used in later patch, where all usage are expected
> > to be optimized away without #ifdef CONFIG_TRANSPARENT_HUGEPAGE.
> > But to detect unexpected usages, we convert existing BUG() to BUILD_BUG().
>
> Just a heads up that this showed up in linux-next today as the
> cause of a new build failure for an ARM board:
Dammit.
> http://kisskb.ellerman.id.au/kisskb/buildresult/5930053/
Site is dead. What was failure, please?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dma-mapping: convert ARCH_HAS_DMA_SET_COHERENT_MASK to kconfig symbol
From: Haojian Zhuang @ 2012-03-21 22:17 UTC (permalink / raw)
To: Rob Herring
Cc: Russell King, Nicolas Pitre, Vinod Koul, Haojian Zhuang,
Rob Herring, Paul Gortmaker, linux-next, Eric Miao, Dan Williams,
Imre Kaloz, linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <4F6A367D.9090102@gmail.com>
On Thu, Mar 22, 2012 at 4:13 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 03/21/2012 03:15 AM, Haojian Zhuang wrote:
>> On Wed, Mar 21, 2012 at 10:30 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>>> On Tue, 20 Mar 2012, Rob Herring wrote:
>>>
>>>> From: Rob Herring <rob.herring@calxeda.com>
>>>>
>>>> The only users of ARCH_HAS_DMA_SET_COHERENT_MASK are 2 ARM platforms:
>>>> ixp4xx and pxa cm_x2xx. We've been getting lucky that the define is
>>>> implicitly included before dma-mapping.h, but the removal of io.h broke
>>>> things (c334bc1 ARM: make mach/io.h include optional). Since memory.h
>>>> is the correct place, but no longer exists, convert the define to a
>>>> kconfig entry.
>>>>
>>>> Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: Imre Kaloz <kaloz@openwrt.org>
>>>> Cc: Krzysztof Halasa <khc@pm.waw.pl>
>>>> Cc: Eric Miao <eric.y.miao@gmail.com>
>>>> Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
>>>> Cc: Vinod Koul <vinod.koul@intel.com>
>>>> Cc: Dan Williams <dan.j.williams@intel.com>
>>>
>>> Acked-by: Nicolas Pitre <nico@linaro.org>
>>>
>> Acked.
>>
>> Imre & Krzysztof,
>>
>> Do you mind that I merge these patches into arch-pxa git tree? Since a
>> lot of files in arch-pxa are changed.
>>
>
> I plan to send these 2 along with another fix to arm-soc if that's okay.
>
> Rob
No problem
^ permalink raw reply
* linux-next: triage for March 21, 2012
From: Paul Gortmaker @ 2012-03-21 22:16 UTC (permalink / raw)
To: linux-next; +Cc: linux-kernel
New breakage since last report:
ARM:tct_hammer_defconfig (pgtable-generic.c: call to '__build_bug_failed')
Randconfig fails that may or may not be new (by their very nature):
powerpc: pseries/iommu.c: 'struct pci_dn' has no member named 'eeh_config_addr'
(http://kisskb.ellerman.id.au/kisskb/buildresult/5930424/)
x86_64: No rule to make scsi/aic7xxx/aicasm/*.[chyl]
(http://kisskb.ellerman.id.au/kisskb/buildresult/5930300/)
Builds that are fixed since last report:
ARM:s3c2410_defconfig
Note: The randconfig fails are only listed once and not tracked
in the below listing.
------------------------------------------------
Latest results at:
http://kisskb.ellerman.id.au/kisskb/branch/9/
Failures as of March 21th, 2012:
===============================
AM33:asb2303_defconfig,asb2364_defconfig
when: Mar 15
why: cc1: error: unrecognized command line option '-mmem-funcs'
status: Possible fix from TonyB sent for review.
fix: http://marc.info/?l=linux-kernel&m=133185020313818&w=2
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5878400/
----------------
ARM:cm_x2xx_defconfig
when: Mar 19
why: it8152.c: redefinition of 'dma_set_coherent_mask'
status: bisected and reported (PaulG)
fix:
ref: http://marc.info/?l=linux-next&m=133226851818586&w=2
ARM:mxs_defconfig
when: Mar 14
why: Inconsistent kallsyms data This is a bug - please report
status: UFO bug keeps appearing at random
fix:
ref: https://lkml.org/lkml/2011/8/2/233
ref: https://lkml.org/lkml/2011/10/8/70
ARM:netx_defconfig,pnx4008_defconfig
when: Mar 14
why: net/core/pktgen.c: can't find a register in class 'GENERAL_REGS'
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5869486/
ref: https://lkml.org/lkml/2012/3/13/670
ARM:cam60_defconfig
when: Feb 23
why: trace_entries.h: 'perf_ftrace_event_register' undeclared
status: S. Rostedt has a patch somewhere.
fix:
ref: irc (#linux-rt)
ARM:collie_defconfig
when: Feb 14
why: locomolcd.c: error: 'sa1100fb_lcd_power' undeclared
status: fixed (PaulG) - pending integration
fix: http://marc.info/?l=linux-next&m=133105157730749&w=2
ref:
ARM:iop32x_defconfig,iop33x_defconfig
when: Nov 23
why: restart.c: implicit declaration of function 'soft_restart'
status: fixed (PaulG) - pending integration
fix: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081461.html
fix: https://lkml.org/lkml/2012/3/14/253
ref:
ARM:ixp4xx_defconfig
when: Oct 26
why: gpio.h: implicit declaration of function '__gpio_get_value'
status: fixed (Imre Kaloz) - but possibly needs rework?
fix: https://lkml.org/lkml/2012/2/8/288
ref: https://lkml.org/lkml/2012/2/8/287
ARM:magician_defconfig
when: Feb 13
why: magician.c: unknown field 'dev' specified in initializer
status: fixed (PaulG) - pending integration
fix:
ref: http://marc.info/?l=linux-next&m=133106325903524&w=2
ARM:em_x270_defconfig
when: Feb 14
why: em-x270.c: unknown field 'dev' specified in initializer
status: fixed (PaulG) - pending integration
fix: http://www.spinics.net/lists/arm-kernel/msg164012.html
ref: http://www.spinics.net/lists/arm-kernel/msg163135.html
ARM:raumfeld_defconfig
when: Nov 23
why: eeti_ts.c: implicit declaration of function 'irq_to_gpio'
status: perhaps broken since 2010? See ref below.
fix:
ref: http://www.gossamer-threads.com/lists/linux/kernel/1291618?do=post_view_threaded#1291618
ARM:omap2plus_defconfig
when: Feb 16, 00:23
why: control.c:238: error: 'OMAP343X_CTRL_BASE' undeclared
status: PaulG did hack-n-slash, but at best a WIP, needs additonal reverts
fix: http://www.spinics.net/lists/arm-kernel/msg163120.html
ref: http://www.spinics.net/lists/arm-kernel/msg163262.html
ARM:at91x40_defconfig
when: Feb 28, 07:38
why: super.c:(.text+0x3ffd8): undefined reference to `vm_is_stack'
status: WIP, fix from PaulG + follow on from
fix: http://marc.info/?l=linux-next&m=133096554131691&w=2
ref: http://marc.info/?l=linux-next&m=133104723928617&w=2
ARM:tct_hammer_defconfig
when: Mar 21
why: pgtable-generic.c: call to '__build_bug_failed' attribute error
status: bisected and reported (PaulG)
fix:
ref: http://marc.info/?l=linux-next&m=133236772927262&w=2
ARM:arm-allnoconfig
when: forever
why: not supported
status: nothing pending, but patches accepted
fix: n/a
ref: https://lkml.org/lkml/2009/4/30/105
ref: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081218.html
----------------
AVR32:defconfig
when: Mar 18
why: board.h: atmel_nand.h: No such file or directory
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5917107/
AVR32:allnoconfig
when: May 26 2010, 20:49
why: at32_map_usart: undefined reference to `atmel_default_console_device'
status:
fix:
ref:
---------------
bfin:***all-builds***
when: Jan 20, 22:13
why: undefined reference to `vm_is_stack'
status: WIP, fix from Siddhesh Poyarekar
fix: http://marc.info/?l=linux-next&m=133096554131691&w=2
ref: http://marc.info/?l=linux-next&m=133104723928617&w=2
---------------
cris:***all-builds***
when: Mar 25, 22:05
why: include/linux/types.h:25: error expected ... before 'ino_t'
status:
fix:
ref:
----------------
crisv32:***all-builds***
when: Mar 25, 22:05
why: include/linux/types.h:25: error expected ... before 'ino_t'
status:
fix:
ref:
----------------
frv:defconfig
when: Mar 15
why: arch/frv/kernel/head.S operand out of range
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5884666/
----------------
h8300:defconfig
when: Mar 15
why: time.c: implicit declaration of function 'get_irq_regs'
why: also seems gcc suffers an ICE
status: ICE bug lodged with gcc folks (TonyB)
fix:
ref: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52598
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5884668/
----------------
i386:allmodconfig
when: Mar 8, 20:41
why: ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
why: ERROR: "mdfld_set_brightness" [drivers/gpu/drm/gma500/gma500_gfx.ko] undefined!
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5878506/
----------------
m32r:m32700ut.smp_defconfig
when: Mar 15
why: No rule to make target `arch/m32r/boot/compressed/vmlinux.bin
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5884670/
----------------
m68k:allmodconfig
when: Mar 16
why: persistent_ram.c: implicit declaration of 'memblock_reserve'
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5884324/
ref: http://www.spinics.net/lists/linux-next/msg19343.html
----------------
mips:allmodconfig
when:
why: driver_pci_host.c: implicit declaration of function 'pcibios_enable_device'
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5807000/
----------------
parisc:allmodconfig
when:
why: include/linux/log2.h: implicit declaration of function 'fls'
status: reported by PaulG, WIP by David Howells
fix:
ref: https://lkml.org/lkml/2012/2/29/409
ref: https://lkml.org/lkml/2012/3/6/228
parisc64:a500_defconfig
when:
why: include/linux/log2.h: implicit declaration of function 'fls'
status: reported by PaulG, WIP by David Howells
fix:
ref: https://lkml.org/lkml/2012/2/29/409
ref: https://lkml.org/lkml/2012/3/6/228
------------------
powerpc:allyesconfig
when: May 18 2009, 22:11
why: fat ass kernel with everything simply won't link
status: need to fix build config to ignore the final link
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5806793/
------------------
sh4:***all-builds***
when: Feb 24, 17:38
why: include/linux/log2.h: implicit declaration of function 'fls'
status: reported by PaulG, WIP by David Howells
fix:
ref: https://lkml.org/lkml/2012/2/29/409
ref: https://lkml.org/lkml/2012/3/6/228
------------------
tilegx:defconfig
when: Mar 19
why: `xfs_qm_exit' defined in discarded section `.exit.text' of fs/built-in.o
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5924094/
------------------
um:um-defconfig
when: Sep 16 2010, 01:28
why: os-Linux/start_up.c: error: 'PTRACE_SETOPTIONS' undeclared
status: clearly broken forever, so does anyone care?
fix:
ref: http://kisskb.ellerman.id.au/kisskb/target/2979/
^ permalink raw reply
* Re: [PATCH v4 2/3] thp: add HPAGE_PMD_* definitions for !CONFIG_TRANSPARENT_HUGEPAGE
From: Paul Gortmaker @ 2012-03-21 22:07 UTC (permalink / raw)
To: Naoya Horiguchi
Cc: Andrew Morton, Andrea Arcangeli, KAMEZAWA Hiroyuki,
Daisuke Nishimura, Hillf Danton, David Rientjes, linux-kernel,
linux-mm, linux-next
In-Reply-To: <1331591456-20769-2-git-send-email-n-horiguchi@ah.jp.nec.com>
On Mon, Mar 12, 2012 at 6:30 PM, Naoya Horiguchi
<n-horiguchi@ah.jp.nec.com> wrote:
> These macros will be used in later patch, where all usage are expected
> to be optimized away without #ifdef CONFIG_TRANSPARENT_HUGEPAGE.
> But to detect unexpected usages, we convert existing BUG() to BUILD_BUG().
Just a heads up that this showed up in linux-next today as the
cause of a new build failure for an ARM board:
http://kisskb.ellerman.id.au/kisskb/buildresult/5930053/
Paul.
--
git bisect start
# good: [fde7d9049e55ab85a390be7f415d74c9f62dd0f9] Linux 3.3-rc7
git bisect good fde7d9049e55ab85a390be7f415d74c9f62dd0f9
# bad: [9166d6581d1ca6795bcd38506c7d29bf39402a7d] Add linux-next
specific files for 20120321
git bisect bad 9166d6581d1ca6795bcd38506c7d29bf39402a7d
# good: [e863be5cac0a857302ccc0129326ca3634c1136a] Merge
remote-tracking branch 'net-next/master'
git bisect good e863be5cac0a857302ccc0129326ca3634c1136a
# good: [2ac4846c531fc33783999e8819a66d0f3e36058f] Merge
remote-tracking branch 'spi/spi/next'
git bisect good 2ac4846c531fc33783999e8819a66d0f3e36058f
# good: [a3ebef77540d27811aab7514b9aeaab13c573b46] Merge
remote-tracking branch 'oprofile/for-next'
git bisect good a3ebef77540d27811aab7514b9aeaab13c573b46
# good: [3ee174051be0246173ba8a386bb7a2d20d9e27c3] [arm-soc internal]
add back contents file
git bisect good 3ee174051be0246173ba8a386bb7a2d20d9e27c3
# good: [cc61a2762110efb0868bc326be52f3ecd22c4e99] Merge
remote-tracking branch 'dma-buf/for-next'
git bisect good cc61a2762110efb0868bc326be52f3ecd22c4e99
# bad: [dd09ea75ddb4d712abe5ec8a9b37619a99d4554c] kernel/watchdog.c:
add comment to watchdog() exit path
git bisect bad dd09ea75ddb4d712abe5ec8a9b37619a99d4554c
# good: [a80d01212507a57d48912f08ca22de039f4470b8] rmap: remove
__anon_vma_link() declaration
git bisect good a80d01212507a57d48912f08ca22de039f4470b8
# good: [dfac39f6a2daa212de0eb80bf14c76a2bee23dc4] memcg: remove
PCG_CACHE page_cgroup flag
git bisect good dfac39f6a2daa212de0eb80bf14c76a2bee23dc4
# bad: [8887892fd3354617e63be2399e286a86d0f9279c] alpha: use
set_current_blocked() and block_sigmask()
git bisect bad 8887892fd3354617e63be2399e286a86d0f9279c
# good: [0d7a67d6525414f8541f4a61084d783b4b53b8ec] memcg: remove
PCG_FILE_MAPPED fix cosmetic fix
git bisect good 0d7a67d6525414f8541f4a61084d783b4b53b8ec
# good: [ea20bf604adaab3a4ffb887083e62e7d76eb5d53] memcg: clean up
existing move charge code
git bisect good ea20bf604adaab3a4ffb887083e62e7d76eb5d53
# bad: [0709378dc1d716112e10de7f687af4993e69df7b] frv: use
set_current_blocked() and block_sigmask()
git bisect bad 0709378dc1d716112e10de7f687af4993e69df7b
# bad: [3135be0275c89f28c352554a0ec1874ea7cd3c3a] memcg: avoid THP
split in task migration
git bisect bad 3135be0275c89f28c352554a0ec1874ea7cd3c3a
# bad: [92c36300cf69f6ea1267d0bba7af708560c116d7] thp: add HPAGE_PMD_*
definitions for !CONFIG_TRANSPARENT_HUGEPAGE
git bisect bad 92c36300cf69f6ea1267d0bba7af708560c116d7
paul@yow-lpgnfs-02:~/git/linux-head$
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Acked-by: Hillf Danton <dhillf@gmail.com>
> Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
> Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Acked-by: David Rientjes <rientjes@google.com>
> ---
> include/linux/huge_mm.h | 11 ++++++-----
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git linux-next-20120307.orig/include/linux/huge_mm.h linux-next-20120307/include/linux/huge_mm.h
> index f56cacb..c8af7a2 100644
> --- linux-next-20120307.orig/include/linux/huge_mm.h
> +++ linux-next-20120307/include/linux/huge_mm.h
> @@ -51,6 +51,9 @@ extern pmd_t *page_check_address_pmd(struct page *page,
> unsigned long address,
> enum page_check_address_pmd_flag flag);
>
> +#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> +#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> +
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> #define HPAGE_PMD_SHIFT HPAGE_SHIFT
> #define HPAGE_PMD_MASK HPAGE_MASK
> @@ -102,8 +105,6 @@ extern void __split_huge_page_pmd(struct mm_struct *mm, pmd_t *pmd);
> BUG_ON(pmd_trans_splitting(*____pmd) || \
> pmd_trans_huge(*____pmd)); \
> } while (0)
> -#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> -#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> #if HPAGE_PMD_ORDER > MAX_ORDER
> #error "hugepages can't be allocated by the buddy allocator"
> #endif
> @@ -158,9 +159,9 @@ static inline struct page *compound_trans_head(struct page *page)
> return page;
> }
> #else /* CONFIG_TRANSPARENT_HUGEPAGE */
> -#define HPAGE_PMD_SHIFT ({ BUG(); 0; })
> -#define HPAGE_PMD_MASK ({ BUG(); 0; })
> -#define HPAGE_PMD_SIZE ({ BUG(); 0; })
> +#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
> +#define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
> +#define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
>
> #define hpage_nr_pages(x) 1
>
> --
> 1.7.7.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (mfd and input trees related)
From: Samuel Ortiz @ 2012-03-21 20:40 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Stephen Rothwell, linux-next, linux-kernel, Donggeun Kim,
Myungjoo Ham, Kyungmin Park
In-Reply-To: <20120321080313.GA12410@core.coreip.homeip.net>
Hi Dmitry, Stephen,
On Wed, Mar 21, 2012 at 01:03:13AM -0700, Dmitry Torokhov wrote:
> > Caused by a bad merge of commits 104594b01ce7 ("Input: add driver support
> > for MAX8997-haptic") from the input tree and 02b09703e7a4 ("mfd: Add
> > platform data for MAX8997 haptic driver") from the mfd tree.
>
> Sorry about this. I thought Samuel was going to revert the platform data
> from his tree as he OKed applying the combined patch...
My fault indeed. The commit is reverted now.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dma-mapping: convert ARCH_HAS_DMA_SET_COHERENT_MASK to kconfig symbol
From: Rob Herring @ 2012-03-21 20:13 UTC (permalink / raw)
To: Haojian Zhuang
Cc: Nicolas Pitre, Russell King, Vinod Koul, Haojian Zhuang,
Rob Herring, Paul Gortmaker, linux-next, Eric Miao, Dan Williams,
Imre Kaloz, linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <CAN1soZwXh6DviO5CHcj_ogM1VK23V2c4CKZf+iMmeP43rwtW9w@mail.gmail.com>
On 03/21/2012 03:15 AM, Haojian Zhuang wrote:
> On Wed, Mar 21, 2012 at 10:30 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Tue, 20 Mar 2012, Rob Herring wrote:
>>
>>> From: Rob Herring <rob.herring@calxeda.com>
>>>
>>> The only users of ARCH_HAS_DMA_SET_COHERENT_MASK are 2 ARM platforms:
>>> ixp4xx and pxa cm_x2xx. We've been getting lucky that the define is
>>> implicitly included before dma-mapping.h, but the removal of io.h broke
>>> things (c334bc1 ARM: make mach/io.h include optional). Since memory.h
>>> is the correct place, but no longer exists, convert the define to a
>>> kconfig entry.
>>>
>>> Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Imre Kaloz <kaloz@openwrt.org>
>>> Cc: Krzysztof Halasa <khc@pm.waw.pl>
>>> Cc: Eric Miao <eric.y.miao@gmail.com>
>>> Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
>>> Cc: Vinod Koul <vinod.koul@intel.com>
>>> Cc: Dan Williams <dan.j.williams@intel.com>
>>
>> Acked-by: Nicolas Pitre <nico@linaro.org>
>>
> Acked.
>
> Imre & Krzysztof,
>
> Do you mind that I merge these patches into arch-pxa git tree? Since a
> lot of files in arch-pxa are changed.
>
I plan to send these 2 along with another fix to arm-soc if that's okay.
Rob
^ permalink raw reply
* [PATCH] android: make persistent_ram based drivers depend on HAVE_MEMBLOCK
From: Colin Cross @ 2012-03-21 17:18 UTC (permalink / raw)
To: linux-kernel, linux-next
Cc: Geert Uytterhoeven, John Stultz, Paul Gortmaker,
Android Kernel Team, gregkh, Linus Torvalds, Colin Cross
m68k doesn't have memblock_reserve, which causes a build failure
with allmodconfig. Make PERSISTENT_RAM and RAM_CONSOLE depend on
HAVE_MEMBLOCK.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Colin Cross <ccross@android.com>
---
drivers/staging/android/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
I can't test on m68k, but this disables the options if I remove
HAVE_MEMBLOCK from arm.
diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 08a3b11..eb1dee2 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -27,13 +27,14 @@ config ANDROID_LOGGER
config ANDROID_PERSISTENT_RAM
bool
+ depends on HAVE_MEMBLOCK
select REED_SOLOMON
select REED_SOLOMON_ENC8
select REED_SOLOMON_DEC8
config ANDROID_RAM_CONSOLE
bool "Android RAM buffer console"
- depends on !S390 && !UML
+ depends on !S390 && !UML && HAVE_MEMBLOCK
select ANDROID_PERSISTENT_RAM
default n
--
1.7.7.3
^ permalink raw reply related
* Re: build failure in linux-next
From: Stephen Rothwell @ 2012-03-21 15:07 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Mark Salter, linux-kernel, linux-next, Andrew Morton
In-Reply-To: <20120321145934.GA24602@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3977 bytes --]
[Cc: akpm]
On Wed, 21 Mar 2012 15:59:34 +0100 Andrea Arcangeli <aarcange@redhat.com> wrote:
>
> On Wed, Mar 21, 2012 at 10:36:14AM -0400, Mark Salter wrote:
> > I'm seeing a build failure in linux-next:
> >
> > CC init/main.o
> > In file included from /es/linux/linux-next/arch/c6x/include/asm/pgtable.h:76:0,
> > from /es/linux/linux-next/include/linux/mm.h:44,
> > from /es/linux/linux-next/include/linux/ring_buffer.h:5,
> > from /es/linux/linux-next/include/linux/ftrace_event.h:4,
> > from /es/linux/linux-next/include/trace/syscall.h:6,
> > from /es/linux/linux-next/include/linux/syscalls.h:78,
> > from /es/linux/linux-next/init/main.c:16:
> > /es/linux/linux-next/include/asm-generic/pgtable.h: In function 'pmd_none_or_trans_huge_or_clear_bad':
> > /es/linux/linux-next/include/asm-generic/pgtable.h:476:4: error: implicit declaration of function 'pmd_clear_bad' [-Werror=implicit-function-declaration]
> >
> >
> > This patch added some functions to asm-generic/pgtable.h which should
> > have been placed in the CONFIG_MMU conditional block:
> >
> > Author: Andrea Arcangeli <aarcange@redhat.com>
> > Date: Wed Mar 21 10:48:00 2012 +1100
> >
> > mm: thp: fix pmd_bad() triggering in code paths holding mmap_sem read mode
> >
> >
> > The following patch fixes the build problem for me:
>
> Thanks for noticing this problem.
>
>
>
> >
> > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> > index 202c010..8ba3ba5 100644
> > --- a/include/asm-generic/pgtable.h
> > +++ b/include/asm-generic/pgtable.h
> > @@ -342,6 +342,64 @@ static inline void ptep_modify_prot_commit(struct mm_struct *mm,
> > __ptep_modify_prot_commit(mm, addr, ptep, pte);
> > }
> > #endif /* __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION */
> > +
> > +/*
> > + * This function is meant to be used by sites walking pagetables with
> > + * the mmap_sem hold in read mode to protect against MADV_DONTNEED and
> > + * transhuge page faults. MADV_DONTNEED can convert a transhuge pmd
> > + * into a null pmd and the transhuge page fault can convert a null pmd
> > + * into an hugepmd or into a regular pmd (if the hugepage allocation
> > + * fails). While holding the mmap_sem in read mode the pmd becomes
> > + * stable and stops changing under us only if it's not null and not a
> > + * transhuge pmd. When those races occurs and this function makes a
> > + * difference vs the standard pmd_none_or_clear_bad, the result is
> > + * undefined so behaving like if the pmd was none is safe (because it
> > + * can return none anyway). The compiler level barrier() is critically
> > + * important to compute the two checks atomically on the same pmdval.
> > + */
> > +static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
> > +{
> > + /* depend on compiler for an atomic pmd read */
> > + pmd_t pmdval = *pmd;
> > + /*
> > + * The barrier will stabilize the pmdval in a register or on
> > + * the stack so that it will stop changing under the code.
> > + */
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > + barrier();
> > +#endif
> > + if (pmd_none(pmdval))
> > + return 1;
> > + if (unlikely(pmd_bad(pmdval))) {
> > + if (!pmd_trans_huge(pmdval))
> > + pmd_clear_bad(pmd);
>
> Problem is, this fixes MMU=n but it'll break x86 with MMU=y and THP=n.
>
> These functions shall be placed after pmd_trans_huge you see at the
> end of asm-generic/pgtable.h .
>
> The simplest fix is that you add #ifdef CONFIG_MMU around it instead
> of moving (I guess you can keep pmd_trans_huge and the rest at the end
> of the file inside CONFIG_MMU too as it shall never be called as it
> all takes pmds/ptes as parameter).
>
> Thanks,
> Andrea
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: build failure in linux-next
From: Stephen Rothwell @ 2012-03-21 15:02 UTC (permalink / raw)
To: Mark Salter; +Cc: aarcange, linux-kernel, linux-next, Andrew Morton
In-Reply-To: <1332340575.12353.55.camel@deneb.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 6826 bytes --]
[cc: akpm]
On Wed, 21 Mar 2012 10:36:14 -0400 Mark Salter <msalter@redhat.com> wrote:
>
> I'm seeing a build failure in linux-next:
>
> CC init/main.o
> In file included from /es/linux/linux-next/arch/c6x/include/asm/pgtable.h:76:0,
> from /es/linux/linux-next/include/linux/mm.h:44,
> from /es/linux/linux-next/include/linux/ring_buffer.h:5,
> from /es/linux/linux-next/include/linux/ftrace_event.h:4,
> from /es/linux/linux-next/include/trace/syscall.h:6,
> from /es/linux/linux-next/include/linux/syscalls.h:78,
> from /es/linux/linux-next/init/main.c:16:
> /es/linux/linux-next/include/asm-generic/pgtable.h: In function 'pmd_none_or_trans_huge_or_clear_bad':
> /es/linux/linux-next/include/asm-generic/pgtable.h:476:4: error: implicit declaration of function 'pmd_clear_bad' [-Werror=implicit-function-declaration]
>
>
> This patch added some functions to asm-generic/pgtable.h which should
> have been placed in the CONFIG_MMU conditional block:
>
> Author: Andrea Arcangeli <aarcange@redhat.com>
> Date: Wed Mar 21 10:48:00 2012 +1100
>
> mm: thp: fix pmd_bad() triggering in code paths holding mmap_sem read mode
>
>
> The following patch fixes the build problem for me:
>
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 202c010..8ba3ba5 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -342,6 +342,64 @@ static inline void ptep_modify_prot_commit(struct mm_struct *mm,
> __ptep_modify_prot_commit(mm, addr, ptep, pte);
> }
> #endif /* __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION */
> +
> +/*
> + * This function is meant to be used by sites walking pagetables with
> + * the mmap_sem hold in read mode to protect against MADV_DONTNEED and
> + * transhuge page faults. MADV_DONTNEED can convert a transhuge pmd
> + * into a null pmd and the transhuge page fault can convert a null pmd
> + * into an hugepmd or into a regular pmd (if the hugepage allocation
> + * fails). While holding the mmap_sem in read mode the pmd becomes
> + * stable and stops changing under us only if it's not null and not a
> + * transhuge pmd. When those races occurs and this function makes a
> + * difference vs the standard pmd_none_or_clear_bad, the result is
> + * undefined so behaving like if the pmd was none is safe (because it
> + * can return none anyway). The compiler level barrier() is critically
> + * important to compute the two checks atomically on the same pmdval.
> + */
> +static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
> +{
> + /* depend on compiler for an atomic pmd read */
> + pmd_t pmdval = *pmd;
> + /*
> + * The barrier will stabilize the pmdval in a register or on
> + * the stack so that it will stop changing under the code.
> + */
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> + barrier();
> +#endif
> + if (pmd_none(pmdval))
> + return 1;
> + if (unlikely(pmd_bad(pmdval))) {
> + if (!pmd_trans_huge(pmdval))
> + pmd_clear_bad(pmd);
> + return 1;
> + }
> + return 0;
> +}
> +
> +/*
> + * This is a noop if Transparent Hugepage Support is not built into
> + * the kernel. Otherwise it is equivalent to
> + * pmd_none_or_trans_huge_or_clear_bad(), and shall only be called in
> + * places that already verified the pmd is not none and they want to
> + * walk ptes while holding the mmap sem in read mode (write mode don't
> + * need this). If THP is not enabled, the pmd can't go away under the
> + * code even if MADV_DONTNEED runs, but if THP is enabled we need to
> + * run a pmd_trans_unstable before walking the ptes after
> + * split_huge_page_pmd returns (because it may have run when the pmd
> + * become null, but then a page fault can map in a THP and not a
> + * regular page).
> + */
> +static inline int pmd_trans_unstable(pmd_t *pmd)
> +{
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> + return pmd_none_or_trans_huge_or_clear_bad(pmd);
> +#else
> + return 0;
> +#endif
> +}
> +
> #endif /* CONFIG_MMU */
>
> /*
> @@ -444,63 +502,6 @@ static inline int pmd_write(pmd_t pmd)
> #endif /* __HAVE_ARCH_PMD_WRITE */
> #endif
>
> -/*
> - * This function is meant to be used by sites walking pagetables with
> - * the mmap_sem hold in read mode to protect against MADV_DONTNEED and
> - * transhuge page faults. MADV_DONTNEED can convert a transhuge pmd
> - * into a null pmd and the transhuge page fault can convert a null pmd
> - * into an hugepmd or into a regular pmd (if the hugepage allocation
> - * fails). While holding the mmap_sem in read mode the pmd becomes
> - * stable and stops changing under us only if it's not null and not a
> - * transhuge pmd. When those races occurs and this function makes a
> - * difference vs the standard pmd_none_or_clear_bad, the result is
> - * undefined so behaving like if the pmd was none is safe (because it
> - * can return none anyway). The compiler level barrier() is critically
> - * important to compute the two checks atomically on the same pmdval.
> - */
> -static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
> -{
> - /* depend on compiler for an atomic pmd read */
> - pmd_t pmdval = *pmd;
> - /*
> - * The barrier will stabilize the pmdval in a register or on
> - * the stack so that it will stop changing under the code.
> - */
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> - barrier();
> -#endif
> - if (pmd_none(pmdval))
> - return 1;
> - if (unlikely(pmd_bad(pmdval))) {
> - if (!pmd_trans_huge(pmdval))
> - pmd_clear_bad(pmd);
> - return 1;
> - }
> - return 0;
> -}
> -
> -/*
> - * This is a noop if Transparent Hugepage Support is not built into
> - * the kernel. Otherwise it is equivalent to
> - * pmd_none_or_trans_huge_or_clear_bad(), and shall only be called in
> - * places that already verified the pmd is not none and they want to
> - * walk ptes while holding the mmap sem in read mode (write mode don't
> - * need this). If THP is not enabled, the pmd can't go away under the
> - * code even if MADV_DONTNEED runs, but if THP is enabled we need to
> - * run a pmd_trans_unstable before walking the ptes after
> - * split_huge_page_pmd returns (because it may have run when the pmd
> - * become null, but then a page fault can map in a THP and not a
> - * regular page).
> - */
> -static inline int pmd_trans_unstable(pmd_t *pmd)
> -{
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> - return pmd_none_or_trans_huge_or_clear_bad(pmd);
> -#else
> - return 0;
> -#endif
> -}
> -
> #endif /* !__ASSEMBLY__ */
>
> #endif /* _ASM_GENERIC_PGTABLE_H */
>
>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: build failure in linux-next
From: Andrea Arcangeli @ 2012-03-21 14:59 UTC (permalink / raw)
To: Mark Salter; +Cc: linux-kernel, linux-next
In-Reply-To: <1332340575.12353.55.camel@deneb.redhat.com>
Hi,
On Wed, Mar 21, 2012 at 10:36:14AM -0400, Mark Salter wrote:
> I'm seeing a build failure in linux-next:
>
> CC init/main.o
> In file included from /es/linux/linux-next/arch/c6x/include/asm/pgtable.h:76:0,
> from /es/linux/linux-next/include/linux/mm.h:44,
> from /es/linux/linux-next/include/linux/ring_buffer.h:5,
> from /es/linux/linux-next/include/linux/ftrace_event.h:4,
> from /es/linux/linux-next/include/trace/syscall.h:6,
> from /es/linux/linux-next/include/linux/syscalls.h:78,
> from /es/linux/linux-next/init/main.c:16:
> /es/linux/linux-next/include/asm-generic/pgtable.h: In function 'pmd_none_or_trans_huge_or_clear_bad':
> /es/linux/linux-next/include/asm-generic/pgtable.h:476:4: error: implicit declaration of function 'pmd_clear_bad' [-Werror=implicit-function-declaration]
>
>
> This patch added some functions to asm-generic/pgtable.h which should
> have been placed in the CONFIG_MMU conditional block:
>
> Author: Andrea Arcangeli <aarcange@redhat.com>
> Date: Wed Mar 21 10:48:00 2012 +1100
>
> mm: thp: fix pmd_bad() triggering in code paths holding mmap_sem read mode
>
>
> The following patch fixes the build problem for me:
Thanks for noticing this problem.
>
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 202c010..8ba3ba5 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -342,6 +342,64 @@ static inline void ptep_modify_prot_commit(struct mm_struct *mm,
> __ptep_modify_prot_commit(mm, addr, ptep, pte);
> }
> #endif /* __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION */
> +
> +/*
> + * This function is meant to be used by sites walking pagetables with
> + * the mmap_sem hold in read mode to protect against MADV_DONTNEED and
> + * transhuge page faults. MADV_DONTNEED can convert a transhuge pmd
> + * into a null pmd and the transhuge page fault can convert a null pmd
> + * into an hugepmd or into a regular pmd (if the hugepage allocation
> + * fails). While holding the mmap_sem in read mode the pmd becomes
> + * stable and stops changing under us only if it's not null and not a
> + * transhuge pmd. When those races occurs and this function makes a
> + * difference vs the standard pmd_none_or_clear_bad, the result is
> + * undefined so behaving like if the pmd was none is safe (because it
> + * can return none anyway). The compiler level barrier() is critically
> + * important to compute the two checks atomically on the same pmdval.
> + */
> +static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
> +{
> + /* depend on compiler for an atomic pmd read */
> + pmd_t pmdval = *pmd;
> + /*
> + * The barrier will stabilize the pmdval in a register or on
> + * the stack so that it will stop changing under the code.
> + */
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> + barrier();
> +#endif
> + if (pmd_none(pmdval))
> + return 1;
> + if (unlikely(pmd_bad(pmdval))) {
> + if (!pmd_trans_huge(pmdval))
> + pmd_clear_bad(pmd);
Problem is, this fixes MMU=n but it'll break x86 with MMU=y and THP=n.
These functions shall be placed after pmd_trans_huge you see at the
end of asm-generic/pgtable.h .
The simplest fix is that you add #ifdef CONFIG_MMU around it instead
of moving (I guess you can keep pmd_trans_huge and the rest at the end
of the file inside CONFIG_MMU too as it shall never be called as it
all takes pmds/ptes as parameter).
Thanks,
Andrea
^ permalink raw reply
* build failure in linux-next
From: Mark Salter @ 2012-03-21 14:36 UTC (permalink / raw)
To: aarcange; +Cc: linux-kernel, linux-next
I'm seeing a build failure in linux-next:
CC init/main.o
In file included from /es/linux/linux-next/arch/c6x/include/asm/pgtable.h:76:0,
from /es/linux/linux-next/include/linux/mm.h:44,
from /es/linux/linux-next/include/linux/ring_buffer.h:5,
from /es/linux/linux-next/include/linux/ftrace_event.h:4,
from /es/linux/linux-next/include/trace/syscall.h:6,
from /es/linux/linux-next/include/linux/syscalls.h:78,
from /es/linux/linux-next/init/main.c:16:
/es/linux/linux-next/include/asm-generic/pgtable.h: In function 'pmd_none_or_trans_huge_or_clear_bad':
/es/linux/linux-next/include/asm-generic/pgtable.h:476:4: error: implicit declaration of function 'pmd_clear_bad' [-Werror=implicit-function-declaration]
This patch added some functions to asm-generic/pgtable.h which should
have been placed in the CONFIG_MMU conditional block:
Author: Andrea Arcangeli <aarcange@redhat.com>
Date: Wed Mar 21 10:48:00 2012 +1100
mm: thp: fix pmd_bad() triggering in code paths holding mmap_sem read mode
The following patch fixes the build problem for me:
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 202c010..8ba3ba5 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -342,6 +342,64 @@ static inline void ptep_modify_prot_commit(struct mm_struct *mm,
__ptep_modify_prot_commit(mm, addr, ptep, pte);
}
#endif /* __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION */
+
+/*
+ * This function is meant to be used by sites walking pagetables with
+ * the mmap_sem hold in read mode to protect against MADV_DONTNEED and
+ * transhuge page faults. MADV_DONTNEED can convert a transhuge pmd
+ * into a null pmd and the transhuge page fault can convert a null pmd
+ * into an hugepmd or into a regular pmd (if the hugepage allocation
+ * fails). While holding the mmap_sem in read mode the pmd becomes
+ * stable and stops changing under us only if it's not null and not a
+ * transhuge pmd. When those races occurs and this function makes a
+ * difference vs the standard pmd_none_or_clear_bad, the result is
+ * undefined so behaving like if the pmd was none is safe (because it
+ * can return none anyway). The compiler level barrier() is critically
+ * important to compute the two checks atomically on the same pmdval.
+ */
+static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
+{
+ /* depend on compiler for an atomic pmd read */
+ pmd_t pmdval = *pmd;
+ /*
+ * The barrier will stabilize the pmdval in a register or on
+ * the stack so that it will stop changing under the code.
+ */
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ barrier();
+#endif
+ if (pmd_none(pmdval))
+ return 1;
+ if (unlikely(pmd_bad(pmdval))) {
+ if (!pmd_trans_huge(pmdval))
+ pmd_clear_bad(pmd);
+ return 1;
+ }
+ return 0;
+}
+
+/*
+ * This is a noop if Transparent Hugepage Support is not built into
+ * the kernel. Otherwise it is equivalent to
+ * pmd_none_or_trans_huge_or_clear_bad(), and shall only be called in
+ * places that already verified the pmd is not none and they want to
+ * walk ptes while holding the mmap sem in read mode (write mode don't
+ * need this). If THP is not enabled, the pmd can't go away under the
+ * code even if MADV_DONTNEED runs, but if THP is enabled we need to
+ * run a pmd_trans_unstable before walking the ptes after
+ * split_huge_page_pmd returns (because it may have run when the pmd
+ * become null, but then a page fault can map in a THP and not a
+ * regular page).
+ */
+static inline int pmd_trans_unstable(pmd_t *pmd)
+{
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ return pmd_none_or_trans_huge_or_clear_bad(pmd);
+#else
+ return 0;
+#endif
+}
+
#endif /* CONFIG_MMU */
/*
@@ -444,63 +502,6 @@ static inline int pmd_write(pmd_t pmd)
#endif /* __HAVE_ARCH_PMD_WRITE */
#endif
-/*
- * This function is meant to be used by sites walking pagetables with
- * the mmap_sem hold in read mode to protect against MADV_DONTNEED and
- * transhuge page faults. MADV_DONTNEED can convert a transhuge pmd
- * into a null pmd and the transhuge page fault can convert a null pmd
- * into an hugepmd or into a regular pmd (if the hugepage allocation
- * fails). While holding the mmap_sem in read mode the pmd becomes
- * stable and stops changing under us only if it's not null and not a
- * transhuge pmd. When those races occurs and this function makes a
- * difference vs the standard pmd_none_or_clear_bad, the result is
- * undefined so behaving like if the pmd was none is safe (because it
- * can return none anyway). The compiler level barrier() is critically
- * important to compute the two checks atomically on the same pmdval.
- */
-static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
-{
- /* depend on compiler for an atomic pmd read */
- pmd_t pmdval = *pmd;
- /*
- * The barrier will stabilize the pmdval in a register or on
- * the stack so that it will stop changing under the code.
- */
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- barrier();
-#endif
- if (pmd_none(pmdval))
- return 1;
- if (unlikely(pmd_bad(pmdval))) {
- if (!pmd_trans_huge(pmdval))
- pmd_clear_bad(pmd);
- return 1;
- }
- return 0;
-}
-
-/*
- * This is a noop if Transparent Hugepage Support is not built into
- * the kernel. Otherwise it is equivalent to
- * pmd_none_or_trans_huge_or_clear_bad(), and shall only be called in
- * places that already verified the pmd is not none and they want to
- * walk ptes while holding the mmap sem in read mode (write mode don't
- * need this). If THP is not enabled, the pmd can't go away under the
- * code even if MADV_DONTNEED runs, but if THP is enabled we need to
- * run a pmd_trans_unstable before walking the ptes after
- * split_huge_page_pmd returns (because it may have run when the pmd
- * become null, but then a page fault can map in a THP and not a
- * regular page).
- */
-static inline int pmd_trans_unstable(pmd_t *pmd)
-{
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- return pmd_none_or_trans_huge_or_clear_bad(pmd);
-#else
- return 0;
-#endif
-}
-
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_GENERIC_PGTABLE_H */
^ permalink raw reply related
* Re: [PATCH] ARM: fix lcd power build failure in collie_defconfig
From: Paul Gortmaker @ 2012-03-21 14:02 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux, rpurdie, linux-arm-kernel, linux-next
In-Reply-To: <4F69CDF2.3020609@gmx.de>
On 12-03-21 08:47 AM, Florian Tobias Schandinat wrote:
> On 03/06/2012 04:31 PM, Paul Gortmaker wrote:
>> Commit 086ada54abaa4316e8603f02410fe8ebc9ba2de1 (linux-next)
>>
>> "FB: sa1100: remove global sa1100fb_.*_power function pointers"
>>
>> got rid of all instances but one in locomolcd.c -- which was
>> conditional on CONFIG_SA1100_COLLIE. The associated .power
>> field which replaces the global is populated in mach-sa1100/collie.c
>> so move the assignment there, but make it conditional on the
>> locomolcd support, so use CONFIG_BACKLIGHT_LOCOMO in that file.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> What about this patch?
> I assumed Russel would pick it up as the commit referenced is also in
> his tree but it looks like this patch is still not in -next. Any reasons
> for this?
Not that I'm aware of. I didn't get any negative feedback or change
requests asking for a v2. There are probably about a half dozen
linux-next build failures in my triage list that I've fixed but
the commits have not yet looped back around through the various
maintainers for one reason or another.
http://marc.info/?l=linux-next&m=133227360822405&w=2
It would be nice to have them all crossed off...
Paul.
---
>
>
> Best regards,
>
> Florian Tobias Schandinat
>
>>
>> diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
>> index 48885b7..c7f418b 100644
>> --- a/arch/arm/mach-sa1100/collie.c
>> +++ b/arch/arm/mach-sa1100/collie.c
>> @@ -313,6 +313,10 @@ static struct sa1100fb_mach_info collie_lcd_info = {
>>
>> .lccr0 = LCCR0_Color | LCCR0_Sngl | LCCR0_Act,
>> .lccr3 = LCCR3_OutEnH | LCCR3_PixRsEdg | LCCR3_ACBsDiv(2),
>> +
>> +#ifdef CONFIG_BACKLIGHT_LOCOMO
>> + .lcd_power = locomolcd_power
>> +#endif
>> };
>>
>> static void __init collie_init(void)
>> diff --git a/arch/arm/mach-sa1100/include/mach/collie.h b/arch/arm/mach-sa1100/include/mach/collie.h
>> index 52acda7..f33679d 100644
>> --- a/arch/arm/mach-sa1100/include/mach/collie.h
>> +++ b/arch/arm/mach-sa1100/include/mach/collie.h
>> @@ -1,7 +1,7 @@
>> /*
>> * arch/arm/mach-sa1100/include/mach/collie.h
>> *
>> - * This file contains the hardware specific definitions for Assabet
>> + * This file contains the hardware specific definitions for Collie
>> * Only include this file from SA1100-specific files.
>> *
>> * ChangeLog:
>> @@ -13,6 +13,7 @@
>> #ifndef __ASM_ARCH_COLLIE_H
>> #define __ASM_ARCH_COLLIE_H
>>
>> +extern void locomolcd_power(int on);
>>
>> #define COLLIE_SCOOP_GPIO_BASE (GPIO_MAX + 1)
>> #define COLLIE_GPIO_CHARGE_ON (COLLIE_SCOOP_GPIO_BASE + 0)
>> diff --git a/drivers/video/backlight/locomolcd.c b/drivers/video/backlight/locomolcd.c
>> index be20b5c..3a6d541 100644
>> --- a/drivers/video/backlight/locomolcd.c
>> +++ b/drivers/video/backlight/locomolcd.c
>> @@ -229,14 +229,7 @@ static struct locomo_driver poodle_lcd_driver = {
>>
>> static int __init locomolcd_init(void)
>> {
>> - int ret = locomo_driver_register(&poodle_lcd_driver);
>> - if (ret)
>> - return ret;
>> -
>> -#ifdef CONFIG_SA1100_COLLIE
>> - sa1100fb_lcd_power = locomolcd_power;
>> -#endif
>> - return 0;
>> + return locomo_driver_register(&poodle_lcd_driver);
>> }
>>
>> static void __exit locomolcd_exit(void)
>
^ permalink raw reply
* Re: linux-next: manual merge of the oprofile tree with the tip tree
From: Stephen Rothwell @ 2012-03-21 13:52 UTC (permalink / raw)
To: Robert Richter
Cc: linux-next, linux-kernel, Lin Ming, Jiri Olsa, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Arnaldo Carvalho de Melo
In-Reply-To: <20120321123348.GJ16322@erda.amd.com>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi Robert,
On Wed, 21 Mar 2012 13:33:48 +0100 Robert Richter <robert.richter@amd.com> wrote:
>
> Yeah, the trees are totally different now. Removed my tree from
> for-next.
OK, thanks.
> Btw, please switch my for-next tree back to kernel.org:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git for-next
Done.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: fix lcd power build failure in collie_defconfig
From: Florian Tobias Schandinat @ 2012-03-21 12:47 UTC (permalink / raw)
To: Paul Gortmaker, linux; +Cc: rpurdie, linux-arm-kernel, linux-next
In-Reply-To: <1331051502-22361-1-git-send-email-paul.gortmaker@windriver.com>
On 03/06/2012 04:31 PM, Paul Gortmaker wrote:
> Commit 086ada54abaa4316e8603f02410fe8ebc9ba2de1 (linux-next)
>
> "FB: sa1100: remove global sa1100fb_.*_power function pointers"
>
> got rid of all instances but one in locomolcd.c -- which was
> conditional on CONFIG_SA1100_COLLIE. The associated .power
> field which replaces the global is populated in mach-sa1100/collie.c
> so move the assignment there, but make it conditional on the
> locomolcd support, so use CONFIG_BACKLIGHT_LOCOMO in that file.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
What about this patch?
I assumed Russel would pick it up as the commit referenced is also in
his tree but it looks like this patch is still not in -next. Any reasons
for this?
Best regards,
Florian Tobias Schandinat
>
> diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
> index 48885b7..c7f418b 100644
> --- a/arch/arm/mach-sa1100/collie.c
> +++ b/arch/arm/mach-sa1100/collie.c
> @@ -313,6 +313,10 @@ static struct sa1100fb_mach_info collie_lcd_info = {
>
> .lccr0 = LCCR0_Color | LCCR0_Sngl | LCCR0_Act,
> .lccr3 = LCCR3_OutEnH | LCCR3_PixRsEdg | LCCR3_ACBsDiv(2),
> +
> +#ifdef CONFIG_BACKLIGHT_LOCOMO
> + .lcd_power = locomolcd_power
> +#endif
> };
>
> static void __init collie_init(void)
> diff --git a/arch/arm/mach-sa1100/include/mach/collie.h b/arch/arm/mach-sa1100/include/mach/collie.h
> index 52acda7..f33679d 100644
> --- a/arch/arm/mach-sa1100/include/mach/collie.h
> +++ b/arch/arm/mach-sa1100/include/mach/collie.h
> @@ -1,7 +1,7 @@
> /*
> * arch/arm/mach-sa1100/include/mach/collie.h
> *
> - * This file contains the hardware specific definitions for Assabet
> + * This file contains the hardware specific definitions for Collie
> * Only include this file from SA1100-specific files.
> *
> * ChangeLog:
> @@ -13,6 +13,7 @@
> #ifndef __ASM_ARCH_COLLIE_H
> #define __ASM_ARCH_COLLIE_H
>
> +extern void locomolcd_power(int on);
>
> #define COLLIE_SCOOP_GPIO_BASE (GPIO_MAX + 1)
> #define COLLIE_GPIO_CHARGE_ON (COLLIE_SCOOP_GPIO_BASE + 0)
> diff --git a/drivers/video/backlight/locomolcd.c b/drivers/video/backlight/locomolcd.c
> index be20b5c..3a6d541 100644
> --- a/drivers/video/backlight/locomolcd.c
> +++ b/drivers/video/backlight/locomolcd.c
> @@ -229,14 +229,7 @@ static struct locomo_driver poodle_lcd_driver = {
>
> static int __init locomolcd_init(void)
> {
> - int ret = locomo_driver_register(&poodle_lcd_driver);
> - if (ret)
> - return ret;
> -
> -#ifdef CONFIG_SA1100_COLLIE
> - sa1100fb_lcd_power = locomolcd_power;
> -#endif
> - return 0;
> + return locomo_driver_register(&poodle_lcd_driver);
> }
>
> static void __exit locomolcd_exit(void)
^ permalink raw reply
* Re: linux-next: manual merge of the oprofile tree with the tip tree
From: Robert Richter @ 2012-03-21 12:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Lin Ming, Jiri Olsa, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Arnaldo Carvalho de Melo
In-Reply-To: <20120321163151.83cad17d5524424938f7576c@canb.auug.org.au>
On 21.03.12 16:31:51, Stephen Rothwell wrote:
> Today's linux-next merge of the oprofile tree got a conflict in
> tools/perf/util/parse-events.c between commit 89812fc81f8d ("perf tools:
> Add parser generator for events parsing") from the tip tree and commit
> 1e48600d2388 ("perf tool: Parse general/raw events from sysfs") from the
> oprofile tree.
>
> I have no idea how to fix this up, so I effectively dropped this patch
> from the oprofile tree.
Yeah, the trees are totally different now. Removed my tree from
for-next.
Btw, please switch my for-next tree back to kernel.org:
git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git for-next
Thanks.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
^ permalink raw reply
* Re: linux-next: build failure after merge of the tip tree
From: Stephen Rothwell @ 2012-03-21 12:29 UTC (permalink / raw)
To: Alan Cox
Cc: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Alan Cox, Andrew Morton
In-Reply-To: <20120321121954.5052ccf2@pyramind.ukuu.org.uk>
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
Hi Alan,
On Wed, 21 Mar 2012 12:19:54 +0000 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> We don't even have a sep_driver.c any more. The massive rework of the SEP
> driver dealt with this.
Excellent, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the tip tree
From: Alan Cox @ 2012-03-21 12:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Alan Cox, Andrew Morton
In-Reply-To: <20120321090038.06c65f50bd0329df8705f2cd@canb.auug.org.au>
On Wed, 21 Mar 2012 09:00:38 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > >
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > >
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> >
> > Looks good to me. Alan, care to send me an update that fixes this
> > driver for real?
>
> Was this ever fixed?
We don't even have a sep_driver.c any more. The massive rework of the SEP
driver dealt with this.
Alan
^ permalink raw reply
* Re: linux-next: build failure after merge of the drivers-x86 tree
From: Matthew Garrett @ 2012-03-21 11:19 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Seth Forshee, Azael Avalos
In-Reply-To: <20120321165204.3b9e1995dc363b685d8018dc@canb.auug.org.au>
Damnit. Sorry, I fixed up the for-linus branch but failed to carry that
over to next. Not Seth's fault, I screwed up when hand-merging his
patch.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: linux-next: build failure after merge of the tip tree
From: Alan Cox @ 2012-03-21 9:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Alan Cox, Andrew Morton
In-Reply-To: <20120321090038.06c65f50bd0329df8705f2cd@canb.auug.org.au>
On Wed, 21 Mar 2012 09:00:38 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > >
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > >
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> >
> > Looks good to me. Alan, care to send me an update that fixes this
> > driver for real?
>
> Was this ever fixed?
I thought it was but apparently it got lost or I dropped the ball. I'll
sort it once git.kernel.org is back and I can pull a currentish -next
tree.
Alan
^ permalink raw reply
* Re: [PATCH v2] x86: export 'pcibios_enabled' as GPL
From: Alan Cox @ 2012-03-21 9:29 UTC (permalink / raw)
To: Wang YanQing
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, Florian Tobias Schandinat, linux-fbdev, x86,
Andrew Morton, tglx, mingo, hpa
In-Reply-To: <20120321043721.GA927@udknight>
On Wed, 21 Mar 2012 12:37:21 +0800
Wang YanQing <udknight@gmail.com> wrote:
> On Sun, Mar 18, 2012 at 06:03:41PM -0700, Randy Dunlap wrote:
> > From: Randy Dunlap <rdunlap@xenotime.net>
> >
> > Export 'pcibios_enabled' so that when uvesafb is built as a
> > loadable module (on X86_32), the build will succeed.
> >
> > ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
> >
> > Patch v2 uses EXPORT_SYMBOL_GPL() as requested.
> >
> > Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> > Cc: Michal Januszewski <spock@gentoo.org>
> > Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: x86@kernel.org
> > ---
> > arch/x86/pci/pcbios.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > --- linux-next-20120313.orig/arch/x86/pci/pcbios.c
> > +++ linux-next-20120313/arch/x86/pci/pcbios.c
> > @@ -27,6 +27,7 @@
> > #define PCIBIOS_HW_TYPE2_SPEC 0x20
> >
> > int pcibios_enabled;
> > +EXPORT_SYMBOL_GPL(pcibios_enabled);
> >
> > /* According to the BIOS specification at:
> > * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
> Acked-by: Wang YanQing <udknight@gmail.com>
NAKked again by Alan Cox <alan@linux.intel.com>
The fb code shouldn't be playing guessing games with thsi variable.
I've pointed out both how to check if NX is enabled and how to set pages
NX/non-NX.
Even if you wanted to check the pci bios state we should export a helper
method.
So NAK.
Alan
^ permalink raw reply
* Re: linux-next: triage for March 14, 2012
From: Geert Uytterhoeven @ 2012-03-21 8:33 UTC (permalink / raw)
To: John Stultz
Cc: Paul Gortmaker, Colin Cross, Android Kernel Team, gregkh,
Linus Torvalds, linux-next, linux-kernel
In-Reply-To: <CAMuHMdV45SBg+cm0+x07SfvY-xpjqb_ZVznn-vD=70G1YZXnFw@mail.gmail.com>
On Thu, Mar 15, 2012 at 09:00, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Mar 15, 2012 at 00:39, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
>> New breakage since last report:
>
> Seems you missed two new failures for m68k/allmodconfig:
>
> include/linux/mmc/core.h:128:20: error: field 'completion' has incomplete type
> make[4]: *** [drivers/mmc/card/mmc_test.o] Error 1
>
> drivers/staging/android/persistent_ram.c:457:2: error: implicit
> declaration of function 'memblock_reserve'
> [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[4]: *** [drivers/staging/android/persistent_ram.o] Error 1
This build failure is now in Linus' tree :-(
http://kisskb.ellerman.id.au/kisskb/buildresult/5926105/
Please fix it. Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] avr32: fix build failures from mis-naming of atmel_nand.h
From: Nicolas Ferre @ 2012-03-21 8:26 UTC (permalink / raw)
To: Hans-Christian Egtvedt, Paul Gortmaker,
Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-arm-kernel, linux-next, linux, David Woodhouse
In-Reply-To: <20120321072632.GA15703@samfundet.no>
On 03/21/2012 08:26 AM, Hans-Christian Egtvedt :
> Around Tue 20 Mar 2012 22:15:28 -0400 or thereabout, Paul Gortmaker wrote:
>> Commit bf4289cba02b8cf770ecd7959ca70839f0dd9d3c (linux-next)
>>
>> "ATMEL: fix nand ecc support"
>>
>> indicated that it wanted to "Move platform data to a common
>> header include/linux/platform_data/atmel_nand.h" and the new
>> header even had re-include protectors with:
>>
>> #ifndef __ATMEL_NAND_H__
>>
>> However, the file that was added was simply called atmel.h
>> and this caused avr32 defconfig to fail with:
>>
>> In file included from arch/avr32/boards/atstk1000/setup.c:22:
>> arch/avr32/mach-at32ap/include/mach/board.h:10:44: error: linux/platform_data/atmel_nand.h: No such file or directory
>> In file included from arch/avr32/boards/atstk1000/setup.c:22:
>> arch/avr32/mach-at32ap/include/mach/board.h:121: warning: 'struct atmel_nand_data' declared inside parameter list
>> arch/avr32/mach-at32ap/include/mach/board.h:121: warning: its scope is only this definition or declaration, which is probably not what you want
>> make[2]: *** [arch/avr32/boards/atstk1000/setup.o] Error 1
>>
>> Rename the file to match the original intention, and fix up the
>> users who reference the bad name without the _nand suffix.
>
> Thanks fixing this.
Yes, we need to fix this. But I would not like to see this
"platform_data/atmel.h" renamed: I think that this file was designed to
collect several common platform data (ie: not just NAND related).
So maybe we should just rename the entry that exists in
mach-at32ap/include/mach/board.h
and remove all occurrences of platform_data/atmel_nand.h
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> CC: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>> CC: Hans-Christian Egtvedt <egtvedt@samfundet.no>
>> CC: David Woodhouse <dwmw2@infradead.org>
>
> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
>
>> ---
>> arch/arm/mach-at91/include/mach/board.h | 2 +-
>> drivers/mtd/nand/atmel_nand.c | 2 +-
>> .../linux/platform_data/{atmel.h => atmel_nand.h} | 0
>> 3 files changed, 2 insertions(+), 2 deletions(-)
>> rename include/linux/platform_data/{atmel.h => atmel_nand.h} (100%)
No please.
>>
>> diff --git a/arch/arm/mach-at91/include/mach/board.h b/arch/arm/mach-at91/include/mach/board.h
>> index 544a5d5..aa0e083 100644
>> --- a/arch/arm/mach-at91/include/mach/board.h
>> +++ b/arch/arm/mach-at91/include/mach/board.h
>> @@ -41,7 +41,7 @@
>> #include <sound/atmel-ac97c.h>
>> #include <linux/serial.h>
>> #include <linux/platform_data/macb.h>
>> -#include <linux/platform_data/atmel.h>
>> +#include <linux/platform_data/atmel_nand.h>
>>
>> /* USB Device */
>> struct at91_udc_data {
>> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
>> index 2165576..7b599a9 100644
>> --- a/drivers/mtd/nand/atmel_nand.c
>> +++ b/drivers/mtd/nand/atmel_nand.c
>> @@ -38,7 +38,7 @@
>> #include <linux/dmaengine.h>
>> #include <linux/gpio.h>
>> #include <linux/io.h>
>> -#include <linux/platform_data/atmel.h>
>> +#include <linux/platform_data/atmel_nand.h>
>>
>> #include <mach/cpu.h>
>>
>> diff --git a/include/linux/platform_data/atmel.h b/include/linux/platform_data/atmel_nand.h
>> similarity index 100%
>> rename from include/linux/platform_data/atmel.h
>> rename to include/linux/platform_data/atmel_nand.h
Best regards,
--
Nicolas Ferre
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox