linux-next: manual merge of the tip tree

linux-next: manual merge of the tip tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

Today's linux-next merge of the kvm-arm tree got conflicts in
mm/mprotect.c between c3d16e1652 (mm: migration: do not lose soft dirty
bit if page is in migration state) from Linus' tree and e920e14c (mm: Do
not flush TLB during protection change if !pte_present &&
!migration_entry) from the tip tree.

I've fixed up as below and can carry as required.

diff --cc mm/mprotect.c
index a3af058,a0302ac..0000000
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@@ -100,12 -89,11 +90,12 @@@ static unsigned long change_pte_range(s
  				 * just be safe and disable write
  				 */
  				make_migration_entry_read(&entry);
 -				set_pte_at(mm, addr, pte,
 -					swp_entry_to_pte(entry));
 -
 +				newpte = swp_entry_to_pte(entry);
 +				if (pte_swp_soft_dirty(oldpte))
 +					newpte = pte_swp_mksoft_dirty(newpte);
 +				set_pte_at(mm, addr, pte, newpte);
+ 				pages++;
  			}
- 			pages++;
  		}
  	} while (pte++, addr += PAGE_SIZE, addr != end);
  	arch_leave_lazy_mmu_mode();

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the tip tree

[Cyrill Gorcunov]

On Thu, Oct 17, 2013 at 10:23:19PM +0100, Mark Brown wrote:
> Today's linux-next merge of the kvm-arm tree got conflicts in
> mm/mprotect.c between c3d16e1652 (mm: migration: do not lose soft dirty
> bit if page is in migration state) from Linus' tree and e920e14c (mm: Do
> not flush TLB during protection change if !pte_present &&
> !migration_entry) from the tip tree.
> 
> I've fixed up as below and can carry as required.
>

Thanks a lot, dirty bit handling looks good!

	Cyrill

Re: linux-next: manual merge of the tip tree

[Russell King - ARM Linux]

On Mon, Oct 28, 2013 at 08:47:22AM +0100, Thierry Reding wrote:
> On Sun, Oct 27, 2013 at 10:00:48AM +0000, Russell King - ARM Linux wrote:
> > On Sun, Oct 27, 2013 at 08:12:37AM +0100, Ingo Molnar wrote:
> > > 
> > > * Will Deacon <will.deacon@arm.com> wrote:
> > > > In future, I'll push back on any perf changes outside of arch/ in my 
> > > > tree, but that doesn't help us get out of the current situation: the 
> > > > patches are currently sitting in rmk's tree for 3.13, so that won't meet 
> > > > with -tip (outside of next) until Linus pulls them both. What can we do 
> > > > about that?
> > > 
> > > Unless you guys want to do a revert I guess there's not much to do but to 
> > > warn Linus in the ARM pull request that a conflict is coming up.
> > 
> > From Will's description, it sounded like this could be quite hairy to
> > fix up, so I'd like to include the conflict resolution in the pull
> > request so Linus has something to refer to if needed.  Could someone
> > please forward me that?
> 
> Hi Russell,
> 
> I've attached the relevant parts of the resolution, although I'm not
> sure if anybody's actually confirmed that it's correct.

I'm not sure whether that can happen any time before -final - Will is
(storm dependent) flying out to Linaro Connect today, and I've no idea
who to turn to for this to be tested for ARM.

I guess we have some time given that Linus has released -rc7 and his
comments during the Kernel Summit/in the rc7 announcement.

Re: linux-next: manual merge of the tip tree

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2298 bytes --]

On Sun, Oct 27, 2013 at 10:00:48AM +0000, Russell King - ARM Linux wrote:
> On Sun, Oct 27, 2013 at 08:12:37AM +0100, Ingo Molnar wrote:
> > 
> > * Will Deacon <will.deacon@arm.com> wrote:
> > > In future, I'll push back on any perf changes outside of arch/ in my 
> > > tree, but that doesn't help us get out of the current situation: the 
> > > patches are currently sitting in rmk's tree for 3.13, so that won't meet 
> > > with -tip (outside of next) until Linus pulls them both. What can we do 
> > > about that?
> > 
> > Unless you guys want to do a revert I guess there's not much to do but to 
> > warn Linus in the ARM pull request that a conflict is coming up.
> 
> From Will's description, it sounded like this could be quite hairy to
> fix up, so I'd like to include the conflict resolution in the pull
> request so Linus has something to refer to if needed.  Could someone
> please forward me that?

Hi Russell,

I've attached the relevant parts of the resolution, although I'm not
sure if anybody's actually confirmed that it's correct. FWIW, if I run

	make tools/perf

I do get the expected output:

	Auto-detecting system features:
	...                     backtrace: [ on  ]
	...                         dwarf: [ on  ]
	...                fortify-source: [ on  ]
	...                         glibc: [ on  ]
	...                          gtk2: [ on  ]
	...                  gtk2-infobar: [ on  ]
	...                      libaudit: [ OFF ]
	...                        libbfd: [ OFF ]
	...                        libelf: [ on  ]
	...             libelf-getphdrnum: [ on  ]
	...                   libelf-mmap: [ on  ]
	...                       libnuma: [ OFF ]
	...                       libperl: [ on  ]
	...                     libpython: [ on  ]
	...             libpython-version: [ OFF ]
	...                      libslang: [ OFF ]
	...                     libunwind: [ on  ]
	...         libunwind-debug-frame: [ OFF ]
	...                       on-exit: [ on  ]
	...                stackprotector: [ on  ]
	...            stackprotector-all: [ on  ]

Which I guess means that the version of libunwind that I have doesn't
enable debug-frame support, but that's as expected according to the
package build script.

Thierry

[-- Attachment #1.2: arm-tip-merge --]
[-- Type: text/plain, Size: 15829 bytes --]

diff --cc tools/perf/config/Makefile
index 75b93d7,c516d6b..e4d06b2
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@@ -29,13 -29,9 +29,13 @@@ ifeq ($(ARCH),x86_64
    NO_PERF_REGS := 0
    LIBUNWIND_LIBS = -lunwind -lunwind-x86_64
  endif
 +ifeq ($(ARCH),arm)
 +  NO_PERF_REGS := 0
 +  LIBUNWIND_LIBS = -lunwind -lunwind-arm
 +endif
  
  ifeq ($(NO_PERF_REGS),0)
-   CFLAGS += -DHAVE_PERF_REGS
+   CFLAGS += -DHAVE_PERF_REGS_SUPPORT
  endif
  
  ifeq ($(src-perf),)
@@@ -93,20 -85,125 +89,126 @@@ CFLAGS += -std=gnu9
  
  EXTLIBS = -lelf -lpthread -lrt -lm -ldl
  
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -fstack-protector-all,-fstack-protector-all),y)
-   CFLAGS += -fstack-protector-all
+ ifneq ($(OUTPUT),)
+   OUTPUT_FEATURES = $(OUTPUT)config/feature-checks/
+   $(shell mkdir -p $(OUTPUT_FEATURES))
  endif
  
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wstack-protector,-Wstack-protector),y)
-   CFLAGS += -Wstack-protector
+ feature_check = $(eval $(feature_check_code))
+ define feature_check_code
+   feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0)
+ endef
+ 
+ feature_set = $(eval $(feature_set_code))
+ define feature_set_code
+   feature-$(1) := 1
+ endef
+ 
+ #
+ # Build the feature check binaries in parallel, ignore errors, ignore return value and suppress output:
+ #
+ 
+ #
+ # Note that this is not a complete list of all feature tests, just
+ # those that are typically built on a fully configured system.
+ #
+ # [ Feature tests not mentioned here have to be built explicitly in
+ #   the rule that uses them - an example for that is the 'bionic'
+ #   feature check. ]
+ #
+ CORE_FEATURE_TESTS =			\
+ 	backtrace			\
+ 	dwarf				\
+ 	fortify-source			\
+ 	glibc				\
+ 	gtk2				\
+ 	gtk2-infobar			\
+ 	libaudit			\
+ 	libbfd				\
+ 	libelf				\
+ 	libelf-getphdrnum		\
+ 	libelf-mmap			\
+ 	libnuma				\
+ 	libperl				\
+ 	libpython			\
+ 	libpython-version		\
+ 	libslang			\
+ 	libunwind			\
++	libunwind-debug-frame		\
+ 	on-exit				\
+ 	stackprotector			\
+ 	stackprotector-all
+ 
+ #
+ # So here we detect whether test-all was rebuilt, to be able
+ # to skip the print-out of the long features list if the file
+ # existed before and after it was built:
+ #
+ ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all),)
+   test-all-failed := 1
+ else
+   test-all-failed := 0
+ endif
+ 
+ #
+ # Special fast-path for the 'all features are available' case:
+ #
+ $(call feature_check,all,$(MSG))
+ 
+ #
+ # Just in case the build freshly failed, make sure we print the
+ # feature matrix:
+ #
+ ifeq ($(feature-all), 0)
+   test-all-failed := 1
+ endif
+ 
+ ifeq ($(test-all-failed),1)
+   $(info )
+   $(info Auto-detecting system features:)
+ endif
+ 
+ ifeq ($(feature-all), 1)
+   #
+   # test-all.c passed - just set all the core feature flags to 1:
+   #
+   $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat)))
+ else
+   $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1)
+   $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat)))
+ endif
+ 
+ #
+ # Print the result of the feature test:
+ #
+ feature_print = $(eval $(feature_print_code)) $(info $(MSG))
+ 
+ define feature_print_code
+   ifeq ($(feature-$(1)), 1)
+     MSG = $(shell printf '...%30s: [ \033[32mon\033[m  ]' $(1))
+   else
+     MSG = $(shell printf '...%30s: [ \033[31mOFF\033[m ]' $(1))
+   endif
+ endef
+ 
+ #
+ # Only print out our features if we rebuilt the testcases or if a test failed:
+ #
+ ifeq ($(test-all-failed), 1)
+   $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_print,$(feat)))
+   $(info )
  endif
  
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wvolatile-register-var,-Wvolatile-register-var),y)
-   CFLAGS += -Wvolatile-register-var
+ ifeq ($(feature-stackprotector-all), 1)
+   CFLAGS += -fstack-protector-all
+ endif
+ 
+ ifeq ($(feature-stackprotector), 1)
+   CFLAGS += -Wstack-protector
  endif
  
- ifndef PERF_DEBUG
-   ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -D_FORTIFY_SOURCE=2,-D_FORTIFY_SOURCE=2),y)
+ ifeq ($(DEBUG),0)
+   ifeq ($(feature-fortify-source), 1)
      CFLAGS += -D_FORTIFY_SOURCE=2
    endif
  endif
@@@ -179,64 -274,55 +279,59 @@@ els
  endif # NO_LIBELF
  
  ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
-   CFLAGS += -DLIBELF_MMAP
- endif
- ifeq ($(call try-cc,$(SOURCE_ELF_GETPHDRNUM),$(FLAGS_LIBELF),-DHAVE_ELF_GETPHDRNUM),y)
-   CFLAGS += -DHAVE_ELF_GETPHDRNUM
- endif
+   CFLAGS += -DHAVE_LIBELF_SUPPORT
  
- # include ARCH specific config
- -include $(src-perf)/arch/$(ARCH)/Makefile
+   ifeq ($(feature-libelf-mmap), 1)
+     CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
+   endif
  
- ifndef NO_DWARF
- ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
-   msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
-   NO_DWARF := 1
- else
-   CFLAGS += -DDWARF_SUPPORT $(LIBDW_CFLAGS)
-   LDFLAGS += $(LIBDW_LDFLAGS)
-   EXTLIBS += -lelf -ldw
- endif # PERF_HAVE_DWARF_REGS
- endif # NO_DWARF
+   ifeq ($(feature-libelf-getphdrnum), 1)
+     CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
+   endif
  
- endif # NO_LIBELF
+   # include ARCH specific config
+   -include $(src-perf)/arch/$(ARCH)/Makefile
  
- ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
-   CFLAGS += -DLIBELF_MMAP
- endif # try-cc
+   ifndef NO_DWARF
+     ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
+       msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
+       NO_DWARF := 1
+     else
+       CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS)
+       LDFLAGS += $(LIBDW_LDFLAGS)
+       EXTLIBS += -lelf -ldw
+     endif # PERF_HAVE_DWARF_REGS
+   endif # NO_DWARF
  endif # NO_LIBELF
  
 -# There's only x86 (both 32 and 64) support for CFI unwind so far
 -ifneq ($(ARCH),x86)
 +ifeq ($(LIBUNWIND_LIBS),)
    NO_LIBUNWIND := 1
  endif
  
  ifndef NO_LIBUNWIND
- # for linking with debug library, run like:
- # make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
- ifdef LIBUNWIND_DIR
-   LIBUNWIND_CFLAGS  := -I$(LIBUNWIND_DIR)/include
-   LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
- endif
+   #
+   # For linking with debug library, run like:
+   #
+   #   make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
+   #
+   ifdef LIBUNWIND_DIR
+     LIBUNWIND_CFLAGS  := -I$(LIBUNWIND_DIR)/include
+     LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
+   endif
  
- FLAGS_UNWIND=$(LIBUNWIND_CFLAGS) $(CFLAGS) $(LIBUNWIND_LDFLAGS) $(LDFLAGS) $(EXTLIBS) $(LIBUNWIND_LIBS)
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND),$(FLAGS_UNWIND),libunwind),y)
-   msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
-   NO_LIBUNWIND := 1
- endif # Libunwind support
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND_DEBUG_FRAME),$(FLAGS_UNWIND),libunwind debug_frame),y)
-   msg := $(warning No debug_frame support found in libunwind);
- CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
- endif # debug_frame support in libunwind
- endif # NO_LIBUNWIND
+   ifneq ($(feature-libunwind), 1)
 -    msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 0.99);
++    msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
+     NO_LIBUNWIND := 1
++  else
++    ifneq ($(feature-libunwind-debug-frame), 1)
++      msg := $(warning No debug_frame support found in libunwind);
++      CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
++    endif
+   endif
+ endif
  
  ifndef NO_LIBUNWIND
-   CFLAGS += -DLIBUNWIND_SUPPORT
+   CFLAGS += -DHAVE_LIBUNWIND_SUPPORT
    EXTLIBS += $(LIBUNWIND_LIBS)
    CFLAGS += $(LIBUNWIND_CFLAGS)
    LDFLAGS += $(LIBUNWIND_LDFLAGS)
diff --cc tools/perf/config/feature-checks/Makefile
index 0000000,452b67c..abaf8f4
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@@ -1,0 -1,144 +1,148 @@@
+ 
+ FILES=					\
+ 	test-all			\
+ 	test-backtrace			\
+ 	test-bionic			\
+ 	test-dwarf			\
+ 	test-fortify-source		\
+ 	test-glibc			\
+ 	test-gtk2			\
+ 	test-gtk2-infobar		\
+ 	test-hello			\
+ 	test-libaudit			\
+ 	test-libbfd			\
+ 	test-liberty			\
+ 	test-liberty-z			\
+ 	test-cplus-demangle		\
+ 	test-libelf			\
+ 	test-libelf-getphdrnum		\
+ 	test-libelf-mmap		\
+ 	test-libnuma			\
+ 	test-libperl			\
+ 	test-libpython			\
+ 	test-libpython-version		\
+ 	test-libslang			\
+ 	test-libunwind			\
++	test-libunwind-debug-frame	\
+ 	test-on-exit			\
+ 	test-stackprotector-all		\
+ 	test-stackprotector
+ 
+ CC := $(CC) -MD
+ 
+ all: $(FILES)
+ 
+ BUILD = $(CC) $(LDFLAGS) -o $(OUTPUT)$@ $@.c
+ 
+ ###############################
+ 
+ test-all:
+ 	$(BUILD) -Werror -fstack-protector -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lunwind -lunwind-x86_64 -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl
+ 
+ test-hello:
+ 	$(BUILD)
+ 
+ test-stackprotector-all:
+ 	$(BUILD) -Werror -fstack-protector-all
+ 
+ test-stackprotector:
+ 	$(BUILD) -Werror -fstack-protector -Wstack-protector
+ 
+ test-fortify-source:
+ 	$(BUILD) -O2 -Werror -D_FORTIFY_SOURCE=2
+ 
+ test-bionic:
+ 	$(BUILD)
+ 
+ test-libelf:
+ 	$(BUILD) -lelf
+ 
+ test-glibc:
+ 	$(BUILD)
+ 
+ test-dwarf:
+ 	$(BUILD) -ldw
+ 
+ test-libelf-mmap:
+ 	$(BUILD) -lelf
+ 
+ test-libelf-getphdrnum:
+ 	$(BUILD) -lelf
+ 
+ test-libnuma:
+ 	$(BUILD) -lnuma
+ 
+ test-libunwind:
+ 	$(BUILD) -lunwind -lunwind-x86_64 -lelf
+ 
++test-libunwind-debug-frame:
++	$(BUILD) -lunwind -lunwind-x86_64 -lelf
++
+ test-libaudit:
+ 	$(BUILD) -laudit
+ 
+ test-libslang:
+ 	$(BUILD) -I/usr/include/slang -lslang
+ 
+ test-gtk2:
+ 	$(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+ 
+ test-gtk2-infobar:
+ 	$(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+ 
+ grep-libs  = $(filter -l%,$(1))
+ strip-libs = $(filter-out -l%,$(1))
+ 
+ PERL_EMBED_LDOPTS = $(shell perl -MExtUtils::Embed -e ldopts 2>/dev/null)
+ PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_CCOPTS = `perl -MExtUtils::Embed -e ccopts 2>/dev/null`
+ FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
+ 
+ test-libperl:
+ 	$(BUILD) $(FLAGS_PERL_EMBED)
+ 
+ override PYTHON := python
+ override PYTHON_CONFIG := python-config
+ 
+ escape-for-shell-sq =  $(subst ','\'',$(1))
+ shell-sq = '$(escape-for-shell-sq)'
+ 
+ PYTHON_CONFIG_SQ = $(call shell-sq,$(PYTHON_CONFIG))
+ 
+ PYTHON_EMBED_LDOPTS = $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
+ PYTHON_EMBED_LDFLAGS = $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_LIBADD = $(call grep-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_CCOPTS = $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+ FLAGS_PYTHON_EMBED = $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
+ 
+ test-libpython:
+ 	$(BUILD) $(FLAGS_PYTHON_EMBED)
+ 
+ test-libpython-version:
+ 	$(BUILD) $(FLAGS_PYTHON_EMBED)
+ 
+ test-libbfd:
+ 	$(BUILD) -DPACKAGE='"perf"' -lbfd -ldl
+ 
+ test-liberty:
+ 	$(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty
+ 
+ test-liberty-z:
+ 	$(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty -lz
+ 
+ test-cplus-demangle:
+ 	$(BUILD) -liberty
+ 
+ test-on-exit:
+ 	$(BUILD)
+ 
+ test-backtrace:
+ 	$(BUILD)
+ 
+ -include *.d
+ 
+ ###############################
+ 
+ clean:
+ 	rm -f $(FILES) *.d
diff --cc tools/perf/config/feature-checks/test-all.c
index 0000000,50d4318..726be48
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/test-all.c
+++ b/tools/perf/config/feature-checks/test-all.c
@@@ -1,0 -1,106 +1,110 @@@
+ /*
+  * test-all.c: Try to build all the main testcases at once.
+  *
+  * A well-configured system will have all the prereqs installed, so we can speed
+  * up auto-detection on such systems.
+  */
+ 
+ /*
+  * Quirk: Python and Perl headers cannot be in arbitrary places, so keep
+  * these 3 testcases at the top:
+  */
+ #define main main_test_libpython
+ # include "test-libpython.c"
+ #undef main
+ 
+ #define main main_test_libpython_version
+ # include "test-libpython-version.c"
+ #undef main
+ 
+ #define main main_test_libperl
+ # include "test-libperl.c"
+ #undef main
+ 
+ #define main main_test_hello
+ # include "test-hello.c"
+ #undef main
+ 
+ #define main main_test_libelf
+ # include "test-libelf.c"
+ #undef main
+ 
+ #define main main_test_libelf_mmap
+ # include "test-libelf-mmap.c"
+ #undef main
+ 
+ #define main main_test_glibc
+ # include "test-glibc.c"
+ #undef main
+ 
+ #define main main_test_dwarf
+ # include "test-dwarf.c"
+ #undef main
+ 
+ #define main main_test_libelf_getphdrnum
+ # include "test-libelf-getphdrnum.c"
+ #undef main
+ 
+ #define main main_test_libunwind
+ # include "test-libunwind.c"
+ #undef main
+ 
++#define main main_test_libunwind_debug_frame
++# include "test-libunwind-debug-frame.c"
++#undef main
++
+ #define main main_test_libaudit
+ # include "test-libaudit.c"
+ #undef main
+ 
+ #define main main_test_libslang
+ # include "test-libslang.c"
+ #undef main
+ 
+ #define main main_test_gtk2
+ # include "test-gtk2.c"
+ #undef main
+ 
+ #define main main_test_gtk2_infobar
+ # include "test-gtk2-infobar.c"
+ #undef main
+ 
+ #define main main_test_libbfd
+ # include "test-libbfd.c"
+ #undef main
+ 
+ #define main main_test_on_exit
+ # include "test-on-exit.c"
+ #undef main
+ 
+ #define main main_test_backtrace
+ # include "test-backtrace.c"
+ #undef main
+ 
+ #define main main_test_libnuma
+ # include "test-libnuma.c"
+ #undef main
+ 
+ int main(int argc, char *argv[])
+ {
+ 	main_test_libpython();
+ 	main_test_libpython_version();
+ 	main_test_libperl();
+ 	main_test_hello();
+ 	main_test_libelf();
+ 	main_test_libelf_mmap();
+ 	main_test_glibc();
+ 	main_test_dwarf();
+ 	main_test_libelf_getphdrnum();
+ 	main_test_libunwind();
+ 	main_test_libaudit();
+ 	main_test_libslang();
+ 	main_test_gtk2(argc, argv);
+ 	main_test_gtk2_infobar(argc, argv);
+ 	main_test_libbfd();
+ 	main_test_on_exit();
+ 	main_test_backtrace();
+ 	main_test_libnuma();
+ 
+ 	return 0;
+ }
diff --cc tools/perf/config/feature-checks/test-libunwind-debug-frame.c
index 0000000,0000000..0ef8087
new file mode 100644
--- /dev/null
+++ b/tools/perf/config/feature-checks/test-libunwind-debug-frame.c
@@@ -1,0 -1,0 +1,16 @@@
++#include <libunwind.h>
++#include <stdlib.h>
++
++extern int
++UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
++				 unw_word_t ip, unw_word_t segbase,
++				 const char *obj_name, unw_word_t start,
++				 unw_word_t end);
++
++#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
++
++int main(void)
++{
++	dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
++	return 0;
++}

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the tip tree

[Russell King - ARM Linux]

On Sun, Oct 27, 2013 at 08:12:37AM +0100, Ingo Molnar wrote:
> 
> * Will Deacon <will.deacon@arm.com> wrote:
> > In future, I'll push back on any perf changes outside of arch/ in my 
> > tree, but that doesn't help us get out of the current situation: the 
> > patches are currently sitting in rmk's tree for 3.13, so that won't meet 
> > with -tip (outside of next) until Linus pulls them both. What can we do 
> > about that?
> 
> Unless you guys want to do a revert I guess there's not much to do but to 
> warn Linus in the ARM pull request that a conflict is coming up.

>From Will's description, it sounded like this could be quite hairy to
fix up, so I'd like to include the conflict resolution in the pull
request so Linus has something to refer to if needed.  Could someone
please forward me that?

Thanks.

Re: linux-next: manual merge of the tip tree

[Ingo Molnar]

* Will Deacon <will.deacon@arm.com> wrote:

> Hi Ingo,
> 
> [adding rmk]
> 
> On Sat, Oct 26, 2013 at 09:40:33AM +0100, Ingo Molnar wrote:
> > * Will Deacon <will.deacon@arm.com> wrote:
> > > On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote:
> > > > I fixed it up (see below). Please verify that the resolution looks good.
> > > > Also note that this isn't really a trivial resolution of a conflict, but
> > > > required modifying various other files. That causes rerere magic not to
> > > > work and needs part of conflict to be resolved manually. Perhaps a good
> > > > idea would be to rebase Jean's patch on top of the cleanups going on in
> > > > the tip tree? Perhaps even carry the patch in the tip tree?
> > > 
> > > These came via my tree (arm perf) after discussion here:
> > > 
> > >   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
> > > 
> > > Now that they've been pulled by rmk, we can't back them out with 
> > > ugly reverts, so I'm not sure what we can do to resolve in the ARM 
> > > tree; it looks like the perf Makefile has changed significantly in 
> > > -tip.
> > 
> > I realize that it was acked by Arnaldo, but for workflow reasons I'd 
> > really prefer it if non-trivial perf tooling patches went to Arnaldo 
> > as a pull request so that he can resolve any such conflicts. perf is 
> > in constant development so it's less work for you that way.
> 
> Sure. I wasn't aware quite how much you guys had planned for the perf 
> Makefile and I (wrongly) assumed that Arnaldo's ack was enough of an 
> indication that conflicts would be unlikely and/or trivial.

That was a bit of unlucky timing.

> In future, I'll push back on any perf changes outside of arch/ in my 
> tree, but that doesn't help us get out of the current situation: the 
> patches are currently sitting in rmk's tree for 3.13, so that won't meet 
> with -tip (outside of next) until Linus pulls them both. What can we do 
> about that?

Unless you guys want to do a revert I guess there's not much to do but to 
warn Linus in the ARM pull request that a conflict is coming up.

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree

[Will Deacon]

Hi Ingo,

[adding rmk]

On Sat, Oct 26, 2013 at 09:40:33AM +0100, Ingo Molnar wrote:
> * Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote:
> > > I fixed it up (see below). Please verify that the resolution looks good.
> > > Also note that this isn't really a trivial resolution of a conflict, but
> > > required modifying various other files. That causes rerere magic not to
> > > work and needs part of conflict to be resolved manually. Perhaps a good
> > > idea would be to rebase Jean's patch on top of the cleanups going on in
> > > the tip tree? Perhaps even carry the patch in the tip tree?
> > 
> > These came via my tree (arm perf) after discussion here:
> > 
> >   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
> > 
> > Now that they've been pulled by rmk, we can't back them out with 
> > ugly reverts, so I'm not sure what we can do to resolve in the ARM 
> > tree; it looks like the perf Makefile has changed significantly in 
> > -tip.
> 
> I realize that it was acked by Arnaldo, but for workflow reasons I'd 
> really prefer it if non-trivial perf tooling patches went to Arnaldo 
> as a pull request so that he can resolve any such conflicts. perf is 
> in constant development so it's less work for you that way.

Sure. I wasn't aware quite how much you guys had planned for the perf
Makefile and I (wrongly) assumed that Arnaldo's ack was enough of an
indication that conflicts would be unlikely and/or trivial.

In future, I'll push back on any perf changes outside of arch/ in my tree,
but that doesn't help us get out of the current situation: the patches are
currently sitting in rmk's tree for 3.13, so that won't meet with -tip
(outside of next) until Linus pulls them both. What can we do about that?

Will

Re: linux-next: manual merge of the tip tree

[Ingo Molnar]

* Will Deacon <will.deacon@arm.com> wrote:

> On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got conflicts in
> > 
> >         tools/perf/config/Makefile
> >         tools/perf/config/feature-tests.mak
> > 
> > caused by commits 405ffbd (perf tools: Check libunwind for availability of
> > dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
> > libunwind logic in config/Makefile) as well as various follow-up patches.
> > 
> > I fixed it up (see below). Please verify that the resolution looks good.
> > Also note that this isn't really a trivial resolution of a conflict, but
> > required modifying various other files. That causes rerere magic not to
> > work and needs part of conflict to be resolved manually. Perhaps a good
> > idea would be to rebase Jean's patch on top of the cleanups going on in
> > the tip tree? Perhaps even carry the patch in the tip tree?
> 
> These came via my tree (arm perf) after discussion here:
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
> 
> Now that they've been pulled by rmk, we can't back them out with 
> ugly reverts, so I'm not sure what we can do to resolve in the ARM 
> tree; it looks like the perf Makefile has changed significantly in 
> -tip.

I realize that it was acked by Arnaldo, but for workflow reasons I'd 
really prefer it if non-trivial perf tooling patches went to Arnaldo 
as a pull request so that he can resolve any such conflicts. perf is 
in constant development so it's less work for you that way.

(Kernel side changes can go that route as well, as long as they are 
perf related.)

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree

[Will Deacon]

On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote:
> Today's linux-next merge of the tip tree got conflicts in
> 
>         tools/perf/config/Makefile
>         tools/perf/config/feature-tests.mak
> 
> caused by commits 405ffbd (perf tools: Check libunwind for availability of
> dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
> libunwind logic in config/Makefile) as well as various follow-up patches.
> 
> I fixed it up (see below). Please verify that the resolution looks good.
> Also note that this isn't really a trivial resolution of a conflict, but
> required modifying various other files. That causes rerere magic not to
> work and needs part of conflict to be resolved manually. Perhaps a good
> idea would be to rebase Jean's patch on top of the cleanups going on in
> the tip tree? Perhaps even carry the patch in the tip tree?

These came via my tree (arm perf) after discussion here:

  http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html

Now that they've been pulled by rmk, we can't back them out with ugly
reverts, so I'm not sure what we can do to resolve in the ARM tree; it looks
like the perf Makefile has changed significantly in -tip.

Will

linux-next: manual merge of the tip tree

[Thierry Reding]

Today's linux-next merge of the tip tree got conflicts in

	tools/perf/config/Makefile
	tools/perf/config/feature-tests.mak

caused by commits 405ffbd (perf tools: Check libunwind for availability of
dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
libunwind logic in config/Makefile) as well as various follow-up patches.

I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?

Thanks,
Thierry
---
diff --cc tools/perf/config/Makefile
index 75b93d7,c516d6b..e4d06b2
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@@ -29,13 -29,9 +29,13 @@@ ifeq ($(ARCH),x86_64
    NO_PERF_REGS := 0
    LIBUNWIND_LIBS = -lunwind -lunwind-x86_64
  endif
 +ifeq ($(ARCH),arm)
 +  NO_PERF_REGS := 0
 +  LIBUNWIND_LIBS = -lunwind -lunwind-arm
 +endif
  
  ifeq ($(NO_PERF_REGS),0)
-   CFLAGS += -DHAVE_PERF_REGS
+   CFLAGS += -DHAVE_PERF_REGS_SUPPORT
  endif
  
  ifeq ($(src-perf),)
@@@ -93,20 -85,125 +89,126 @@@ CFLAGS += -std=gnu9
  
  EXTLIBS = -lelf -lpthread -lrt -lm -ldl
  
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -fstack-protector-all,-fstack-protector-all),y)
-   CFLAGS += -fstack-protector-all
+ ifneq ($(OUTPUT),)
+   OUTPUT_FEATURES = $(OUTPUT)config/feature-checks/
+   $(shell mkdir -p $(OUTPUT_FEATURES))
  endif
  
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wstack-protector,-Wstack-protector),y)
-   CFLAGS += -Wstack-protector
+ feature_check = $(eval $(feature_check_code))
+ define feature_check_code
+   feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0)
+ endef
+ 
+ feature_set = $(eval $(feature_set_code))
+ define feature_set_code
+   feature-$(1) := 1
+ endef
+ 
+ #
+ # Build the feature check binaries in parallel, ignore errors, ignore return value and suppress output:
+ #
+ 
+ #
+ # Note that this is not a complete list of all feature tests, just
+ # those that are typically built on a fully configured system.
+ #
+ # [ Feature tests not mentioned here have to be built explicitly in
+ #   the rule that uses them - an example for that is the 'bionic'
+ #   feature check. ]
+ #
+ CORE_FEATURE_TESTS =			\
+ 	backtrace			\
+ 	dwarf				\
+ 	fortify-source			\
+ 	glibc				\
+ 	gtk2				\
+ 	gtk2-infobar			\
+ 	libaudit			\
+ 	libbfd				\
+ 	libelf				\
+ 	libelf-getphdrnum		\
+ 	libelf-mmap			\
+ 	libnuma				\
+ 	libperl				\
+ 	libpython			\
+ 	libpython-version		\
+ 	libslang			\
+ 	libunwind			\
++	libunwind-debug-frame		\
+ 	on-exit				\
+ 	stackprotector			\
+ 	stackprotector-all
+ 
+ #
+ # So here we detect whether test-all was rebuilt, to be able
+ # to skip the print-out of the long features list if the file
+ # existed before and after it was built:
+ #
+ ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all),)
+   test-all-failed := 1
+ else
+   test-all-failed := 0
+ endif
+ 
+ #
+ # Special fast-path for the 'all features are available' case:
+ #
+ $(call feature_check,all,$(MSG))
+ 
+ #
+ # Just in case the build freshly failed, make sure we print the
+ # feature matrix:
+ #
+ ifeq ($(feature-all), 0)
+   test-all-failed := 1
+ endif
+ 
+ ifeq ($(test-all-failed),1)
+   $(info )
+   $(info Auto-detecting system features:)
+ endif
+ 
+ ifeq ($(feature-all), 1)
+   #
+   # test-all.c passed - just set all the core feature flags to 1:
+   #
+   $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat)))
+ else
+   $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1)
+   $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat)))
+ endif
+ 
+ #
+ # Print the result of the feature test:
+ #
+ feature_print = $(eval $(feature_print_code)) $(info $(MSG))
+ 
+ define feature_print_code
+   ifeq ($(feature-$(1)), 1)
+     MSG = $(shell printf '...%30s: [ \033[32mon\033[m  ]' $(1))
+   else
+     MSG = $(shell printf '...%30s: [ \033[31mOFF\033[m ]' $(1))
+   endif
+ endef
+ 
+ #
+ # Only print out our features if we rebuilt the testcases or if a test failed:
+ #
+ ifeq ($(test-all-failed), 1)
+   $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_print,$(feat)))
+   $(info )
  endif
  
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wvolatile-register-var,-Wvolatile-register-var),y)
-   CFLAGS += -Wvolatile-register-var
+ ifeq ($(feature-stackprotector-all), 1)
+   CFLAGS += -fstack-protector-all
+ endif
+ 
+ ifeq ($(feature-stackprotector), 1)
+   CFLAGS += -Wstack-protector
  endif
  
- ifndef PERF_DEBUG
-   ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -D_FORTIFY_SOURCE=2,-D_FORTIFY_SOURCE=2),y)
+ ifeq ($(DEBUG),0)
+   ifeq ($(feature-fortify-source), 1)
      CFLAGS += -D_FORTIFY_SOURCE=2
    endif
  endif
@@@ -179,64 -274,55 +279,59 @@@ els
  endif # NO_LIBELF
  
  ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
-   CFLAGS += -DLIBELF_MMAP
- endif
- ifeq ($(call try-cc,$(SOURCE_ELF_GETPHDRNUM),$(FLAGS_LIBELF),-DHAVE_ELF_GETPHDRNUM),y)
-   CFLAGS += -DHAVE_ELF_GETPHDRNUM
- endif
+   CFLAGS += -DHAVE_LIBELF_SUPPORT
  
- # include ARCH specific config
- -include $(src-perf)/arch/$(ARCH)/Makefile
+   ifeq ($(feature-libelf-mmap), 1)
+     CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
+   endif
  
- ifndef NO_DWARF
- ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
-   msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
-   NO_DWARF := 1
- else
-   CFLAGS += -DDWARF_SUPPORT $(LIBDW_CFLAGS)
-   LDFLAGS += $(LIBDW_LDFLAGS)
-   EXTLIBS += -lelf -ldw
- endif # PERF_HAVE_DWARF_REGS
- endif # NO_DWARF
+   ifeq ($(feature-libelf-getphdrnum), 1)
+     CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
+   endif
  
- endif # NO_LIBELF
+   # include ARCH specific config
+   -include $(src-perf)/arch/$(ARCH)/Makefile
  
- ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
-   CFLAGS += -DLIBELF_MMAP
- endif # try-cc
+   ifndef NO_DWARF
+     ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
+       msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
+       NO_DWARF := 1
+     else
+       CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS)
+       LDFLAGS += $(LIBDW_LDFLAGS)
+       EXTLIBS += -lelf -ldw
+     endif # PERF_HAVE_DWARF_REGS
+   endif # NO_DWARF
  endif # NO_LIBELF
  
 -# There's only x86 (both 32 and 64) support for CFI unwind so far
 -ifneq ($(ARCH),x86)
 +ifeq ($(LIBUNWIND_LIBS),)
    NO_LIBUNWIND := 1
  endif
  
  ifndef NO_LIBUNWIND
- # for linking with debug library, run like:
- # make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
- ifdef LIBUNWIND_DIR
-   LIBUNWIND_CFLAGS  := -I$(LIBUNWIND_DIR)/include
-   LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
- endif
+   #
+   # For linking with debug library, run like:
+   #
+   #   make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
+   #
+   ifdef LIBUNWIND_DIR
+     LIBUNWIND_CFLAGS  := -I$(LIBUNWIND_DIR)/include
+     LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
+   endif
  
- FLAGS_UNWIND=$(LIBUNWIND_CFLAGS) $(CFLAGS) $(LIBUNWIND_LDFLAGS) $(LDFLAGS) $(EXTLIBS) $(LIBUNWIND_LIBS)
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND),$(FLAGS_UNWIND),libunwind),y)
-   msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
-   NO_LIBUNWIND := 1
- endif # Libunwind support
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND_DEBUG_FRAME),$(FLAGS_UNWIND),libunwind debug_frame),y)
-   msg := $(warning No debug_frame support found in libunwind);
- CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
- endif # debug_frame support in libunwind
- endif # NO_LIBUNWIND
+   ifneq ($(feature-libunwind), 1)
 -    msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 0.99);
++    msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
+     NO_LIBUNWIND := 1
++  else
++    ifneq ($(feature-libunwind-debug-frame), 1)
++      msg := $(warning No debug_frame support found in libunwind);
++      CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
++    endif
+   endif
+ endif
  
  ifndef NO_LIBUNWIND
-   CFLAGS += -DLIBUNWIND_SUPPORT
+   CFLAGS += -DHAVE_LIBUNWIND_SUPPORT
    EXTLIBS += $(LIBUNWIND_LIBS)
    CFLAGS += $(LIBUNWIND_CFLAGS)
    LDFLAGS += $(LIBUNWIND_LDFLAGS)
diff --cc tools/perf/config/feature-checks/Makefile
index 0000000,452b67c..abaf8f4
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@@ -1,0 -1,144 +1,148 @@@
+ 
+ FILES=					\
+ 	test-all			\
+ 	test-backtrace			\
+ 	test-bionic			\
+ 	test-dwarf			\
+ 	test-fortify-source		\
+ 	test-glibc			\
+ 	test-gtk2			\
+ 	test-gtk2-infobar		\
+ 	test-hello			\
+ 	test-libaudit			\
+ 	test-libbfd			\
+ 	test-liberty			\
+ 	test-liberty-z			\
+ 	test-cplus-demangle		\
+ 	test-libelf			\
+ 	test-libelf-getphdrnum		\
+ 	test-libelf-mmap		\
+ 	test-libnuma			\
+ 	test-libperl			\
+ 	test-libpython			\
+ 	test-libpython-version		\
+ 	test-libslang			\
+ 	test-libunwind			\
++	test-libunwind-debug-frame	\
+ 	test-on-exit			\
+ 	test-stackprotector-all		\
+ 	test-stackprotector
+ 
+ CC := $(CC) -MD
+ 
+ all: $(FILES)
+ 
+ BUILD = $(CC) $(LDFLAGS) -o $(OUTPUT)$@ $@.c
+ 
+ ###############################
+ 
+ test-all:
+ 	$(BUILD) -Werror -fstack-protector -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lunwind -lunwind-x86_64 -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl
+ 
+ test-hello:
+ 	$(BUILD)
+ 
+ test-stackprotector-all:
+ 	$(BUILD) -Werror -fstack-protector-all
+ 
+ test-stackprotector:
+ 	$(BUILD) -Werror -fstack-protector -Wstack-protector
+ 
+ test-fortify-source:
+ 	$(BUILD) -O2 -Werror -D_FORTIFY_SOURCE=2
+ 
+ test-bionic:
+ 	$(BUILD)
+ 
+ test-libelf:
+ 	$(BUILD) -lelf
+ 
+ test-glibc:
+ 	$(BUILD)
+ 
+ test-dwarf:
+ 	$(BUILD) -ldw
+ 
+ test-libelf-mmap:
+ 	$(BUILD) -lelf
+ 
+ test-libelf-getphdrnum:
+ 	$(BUILD) -lelf
+ 
+ test-libnuma:
+ 	$(BUILD) -lnuma
+ 
+ test-libunwind:
+ 	$(BUILD) -lunwind -lunwind-x86_64 -lelf
+ 
++test-libunwind-debug-frame:
++	$(BUILD) -lunwind -lunwind-x86_64 -lelf
++
+ test-libaudit:
+ 	$(BUILD) -laudit
+ 
+ test-libslang:
+ 	$(BUILD) -I/usr/include/slang -lslang
+ 
+ test-gtk2:
+ 	$(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+ 
+ test-gtk2-infobar:
+ 	$(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+ 
+ grep-libs  = $(filter -l%,$(1))
+ strip-libs = $(filter-out -l%,$(1))
+ 
+ PERL_EMBED_LDOPTS = $(shell perl -MExtUtils::Embed -e ldopts 2>/dev/null)
+ PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_CCOPTS = `perl -MExtUtils::Embed -e ccopts 2>/dev/null`
+ FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
+ 
+ test-libperl:
+ 	$(BUILD) $(FLAGS_PERL_EMBED)
+ 
+ override PYTHON := python
+ override PYTHON_CONFIG := python-config
+ 
+ escape-for-shell-sq =  $(subst ','\'',$(1))
+ shell-sq = '$(escape-for-shell-sq)'
+ 
+ PYTHON_CONFIG_SQ = $(call shell-sq,$(PYTHON_CONFIG))
+ 
+ PYTHON_EMBED_LDOPTS = $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
+ PYTHON_EMBED_LDFLAGS = $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_LIBADD = $(call grep-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_CCOPTS = $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+ FLAGS_PYTHON_EMBED = $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
+ 
+ test-libpython:
+ 	$(BUILD) $(FLAGS_PYTHON_EMBED)
+ 
+ test-libpython-version:
+ 	$(BUILD) $(FLAGS_PYTHON_EMBED)
+ 
+ test-libbfd:
+ 	$(BUILD) -DPACKAGE='"perf"' -lbfd -ldl
+ 
+ test-liberty:
+ 	$(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty
+ 
+ test-liberty-z:
+ 	$(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty -lz
+ 
+ test-cplus-demangle:
+ 	$(BUILD) -liberty
+ 
+ test-on-exit:
+ 	$(BUILD)
+ 
+ test-backtrace:
+ 	$(BUILD)
+ 
+ -include *.d
+ 
+ ###############################
+ 
+ clean:
+ 	rm -f $(FILES) *.d
diff --cc tools/perf/config/feature-checks/test-all.c
index 0000000,50d4318..ed8aa7b
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/test-all.c
+++ b/tools/perf/config/feature-checks/test-all.c
@@@ -1,0 -1,106 +1,111 @@@
+ /*
+  * test-all.c: Try to build all the main testcases at once.
+  *
+  * A well-configured system will have all the prereqs installed, so we can speed
+  * up auto-detection on such systems.
+  */
+ 
+ /*
+  * Quirk: Python and Perl headers cannot be in arbitrary places, so keep
+  * these 3 testcases at the top:
+  */
+ #define main main_test_libpython
+ # include "test-libpython.c"
+ #undef main
+ 
+ #define main main_test_libpython_version
+ # include "test-libpython-version.c"
+ #undef main
+ 
+ #define main main_test_libperl
+ # include "test-libperl.c"
+ #undef main
+ 
+ #define main main_test_hello
+ # include "test-hello.c"
+ #undef main
+ 
+ #define main main_test_libelf
+ # include "test-libelf.c"
+ #undef main
+ 
+ #define main main_test_libelf_mmap
+ # include "test-libelf-mmap.c"
+ #undef main
+ 
+ #define main main_test_glibc
+ # include "test-glibc.c"
+ #undef main
+ 
+ #define main main_test_dwarf
+ # include "test-dwarf.c"
+ #undef main
+ 
+ #define main main_test_libelf_getphdrnum
+ # include "test-libelf-getphdrnum.c"
+ #undef main
+ 
+ #define main main_test_libunwind
+ # include "test-libunwind.c"
+ #undef main
+ 
++#define main main_test_libunwind_debug_frame
++# include "test-libunwind-debug-frame.c"
++#undef main
++
+ #define main main_test_libaudit
+ # include "test-libaudit.c"
+ #undef main
+ 
+ #define main main_test_libslang
+ # include "test-libslang.c"
+ #undef main
+ 
+ #define main main_test_gtk2
+ # include "test-gtk2.c"
+ #undef main
+ 
+ #define main main_test_gtk2_infobar
+ # include "test-gtk2-infobar.c"
+ #undef main
+ 
+ #define main main_test_libbfd
+ # include "test-libbfd.c"
+ #undef main
+ 
+ #define main main_test_on_exit
+ # include "test-on-exit.c"
+ #undef main
+ 
+ #define main main_test_backtrace
+ # include "test-backtrace.c"
+ #undef main
+ 
+ #define main main_test_libnuma
+ # include "test-libnuma.c"
+ #undef main
+ 
+ int main(int argc, char *argv[])
+ {
+ 	main_test_libpython();
+ 	main_test_libpython_version();
+ 	main_test_libperl();
+ 	main_test_hello();
+ 	main_test_libelf();
+ 	main_test_libelf_mmap();
+ 	main_test_glibc();
+ 	main_test_dwarf();
+ 	main_test_libelf_getphdrnum();
+ 	main_test_libunwind();
++	main_test_libunwind_debug_frame();
+ 	main_test_libaudit();
+ 	main_test_libslang();
+ 	main_test_gtk2(argc, argv);
+ 	main_test_gtk2_infobar(argc, argv);
+ 	main_test_libbfd();
+ 	main_test_on_exit();
+ 	main_test_backtrace();
+ 	main_test_libnuma();
+ 
+ 	return 0;
+ }
diff --cc tools/perf/config/feature-checks/test-libunwind-debug-frame.c
index 0000000,0000000..0ef8087
new file mode 100644
--- /dev/null
+++ b/tools/perf/config/feature-checks/test-libunwind-debug-frame.c
@@@ -1,0 -1,0 +1,16 @@@
++#include <libunwind.h>
++#include <stdlib.h>
++
++extern int
++UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
++				 unw_word_t ip, unw_word_t segbase,
++				 const char *obj_name, unw_word_t start,
++				 unw_word_t end);
++
++#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
++
++int main(void)
++{
++	dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
++	return 0;
++}

Re: linux-next: manual merge of the tip tree

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

On Thu, 17 Oct 2013 11:23:49 +0200 Peter Zijlstra <peterz@infradead.org>
wrote:

> On Thu, Oct 17, 2013 at 12:28:59PM +1100, NeilBrown wrote:
> > I always run with lockdep enabled, and I have done at least basic testing
> 
> Very good!
> 
> > > 
> > > Stuff like:
> > > 
> > > +	for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> > > +		spin_lock_init(conf->hash_locks + i);
> > > 
> > > And:
> > > 
> > > +static void __lock_all_hash_locks(struct r5conf *conf)
> > > +{
> > > +	int i;
> > > +	for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> > > +		spin_lock(conf->hash_locks + i);
> > > +}
> > > 
> > > Tends to complain real loud.
> > 
> > Why is that?
> > Because "conf->hash_locks + i" gets used as the "name" of the lockdep map for
> > each one, and when they are all locked it looks like nested locking??
> 
> Exactly so; they all share the same class (and name) because they have
> the same init site; so indeed the multiple lock will look like a nested
> lock.
> 
> > Do you have a suggestion for how to make this work?
> > Would
> >     spin_lock_nested(conf->hash_locks + i, i)
> > do the trick?
> 
> 	spin_lock_nest_lock(conf->hash_locks + i, &conf->device_lock);

Unfortunately this doesn't work as the order is backwards.
hash_lock is taken first, then (when necessary) device lock.
(hash_lock is needed more often, so we split it up to reduce contention.
 device lock is needed less often, but sometimes when hash_lock is held).

I've currently got:
	spin_lock_init(conf->hash_locks);
	for (i = 1; i < NR_STRIPE_HASH_LOCKS; i++)
		spin_lock_init(conf->hash_locks + i);

and

	spin_lock(conf->hash_locks);
	for (i = 1; i < NR_STRIPE_HASH_LOCKS; i++)
		spin_lock_nest_lock(conf->hash_locks + i, conf->hash_locks);
	spin_lock(&conf->device_lock);

which doesn't trigger any lockdep warnings and isn't too ugly.

Does it seem OK to you?

Thanks,
NeilBrown


> 
> Would be the better option; your suggestion might just work because
> NR_STRIP_HASH_LOCKS is 8 and we have exactly 8 subclasses available, but
> any increase to NR_STRIPE_HASH_LOCKS will make things explode again.
> 
> The spin_lock_nest_lock() annotation tells that the lock order is
> irrelevant because all such multiple acquisitions are serialized under
> the other lock.
> 
> Also, if in future you feel the need to increase NR_STRIP_HASH_LOCKS,
> please keep it <= 64 or so; if you have a need to go above that, please
> yell and we'll see if we can do something smarter.

I've added a comment to this effect in the code.


> 
> This is because of:
>  - each spin_lock() increases preempt_count and that's 8 bits; we
>    wouldn't want to overflow that
>  - each consecutive nested spin_lock() increases the total acquisition
>    wait-time for all locks. Note that the worst case acquisition time
>    for even a single hash lock is gated by the complete acquisition time
>    of all of them in this scenario.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: linux-next: manual merge of the tip tree

[Peter Zijlstra]

On Thu, Oct 17, 2013 at 12:28:59PM +1100, NeilBrown wrote:
> I always run with lockdep enabled, and I have done at least basic testing

Very good!

> > 
> > Stuff like:
> > 
> > +	for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> > +		spin_lock_init(conf->hash_locks + i);
> > 
> > And:
> > 
> > +static void __lock_all_hash_locks(struct r5conf *conf)
> > +{
> > +	int i;
> > +	for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> > +		spin_lock(conf->hash_locks + i);
> > +}
> > 
> > Tends to complain real loud.
> 
> Why is that?
> Because "conf->hash_locks + i" gets used as the "name" of the lockdep map for
> each one, and when they are all locked it looks like nested locking??

Exactly so; they all share the same class (and name) because they have
the same init site; so indeed the multiple lock will look like a nested
lock.

> Do you have a suggestion for how to make this work?
> Would
>     spin_lock_nested(conf->hash_locks + i, i)
> do the trick?

	spin_lock_nest_lock(conf->hash_locks + i, &conf->device_lock);

Would be the better option; your suggestion might just work because
NR_STRIP_HASH_LOCKS is 8 and we have exactly 8 subclasses available, but
any increase to NR_STRIPE_HASH_LOCKS will make things explode again.

The spin_lock_nest_lock() annotation tells that the lock order is
irrelevant because all such multiple acquisitions are serialized under
the other lock.

Also, if in future you feel the need to increase NR_STRIP_HASH_LOCKS,
please keep it <= 64 or so; if you have a need to go above that, please
yell and we'll see if we can do something smarter.

This is because of:
 - each spin_lock() increases preempt_count and that's 8 bits; we
   wouldn't want to overflow that
 - each consecutive nested spin_lock() increases the total acquisition
   wait-time for all locks. Note that the worst case acquisition time
   for even a single hash lock is gated by the complete acquisition time
   of all of them in this scenario.

Re: linux-next: manual merge of the tip tree

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On Wed, 16 Oct 2013 23:30:05 +0200 Peter Zijlstra <peterz@infradead.org>
wrote:

> On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got a conflict in
> > 
> > 	include/linux/wait.h
> > 
> > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > (sched/wait: Clean up wait.h details a bit).
> > 
> > I've cleaned it up (see below). Please verify that the resolution looks
> > good.
> 
> >  +#define __wait_event_cmd(wq, condition, cmd1, cmd2)			\
> >  +do {									\
> >  +	DEFINE_WAIT(__wait);						\
> >  +									\
> >  +	for (;;) {							\
> >  +		prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);	\
> >  +		if (condition)						\
> >  +			break;						\
> >  +		cmd1;							\
> >  +		schedule();						\
> >  +		cmd2;							\
> >  +	}								\
> >  +	finish_wait(&wq, &__wait);					\
> >  +} while (0)
> 
> Ideally we'd write the new thing like:
> 
> #define __wait_event_cmd(wq, condition, cmd1, cmd2) 			\
> 	(void)___wait_event(wq, condition, TASK_UNINTERRUPTIBLE, 0, 0,	\
> 			    cmd1; schedule(); cmd2)
> 

Oooo.. that looks much nicer.  I'll make it look like that before it goes
upstream.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: linux-next: manual merge of the tip tree

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

On Wed, 16 Oct 2013 22:52:07 +0200 Peter Zijlstra <peterz@infradead.org>
wrote:

> Hey Neil;
> 
> it looks like its one of your patches isn't it?
> 
> http://www.spinics.net/lists/raid/msg44100.html
> http://www.spinics.net/lists/raid/msg44101.html
> 
> Given that I can't find them in a lkml archive means nobody's ever seen
> those patches.
> 
> Anyway; has that 3/3 patch ever been ran with lockdep enabled? 

I always run with lockdep enabled, and I have done at least basic testing
(I've been on leave for a few weeks and don't remember exactly where I got
to).
And I haven't seen any lockdep reports.

> 
> Stuff like:
> 
> +	for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> +		spin_lock_init(conf->hash_locks + i);
> 
> And:
> 
> +static void __lock_all_hash_locks(struct r5conf *conf)
> +{
> +	int i;
> +	for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> +		spin_lock(conf->hash_locks + i);
> +}
> 
> Tends to complain real loud.

Why is that?
Because "conf->hash_locks + i" gets used as the "name" of the lockdep map for
each one, and when they are all locked it looks like nested locking??

the lock_all_hash_locks doesn't get called very often and my testing mustn't
have got that far.  I just tried something that would trigger the 
"lock_all_device_hash_locks_irq" (as it is in the current version) and it
went "splat" just as you said it would.
Thanks.

Do you have a suggestion for how to make this work?
Would
    spin_lock_nested(conf->hash_locks + i, i)
do the trick?

Thanks,
NeilBrown

> 
> This leaves one to wonder... 
>   'fancy' locking scheme:1, validation effort:0
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: linux-next: manual merge of the tip tree

[Peter Zijlstra]

On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> Today's linux-next merge of the tip tree got a conflict in
> 
> 	include/linux/wait.h
> 
> caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> (sched/wait: Clean up wait.h details a bit).
> 
> I've cleaned it up (see below). Please verify that the resolution looks
> good.

>  +#define __wait_event_cmd(wq, condition, cmd1, cmd2)			\
>  +do {									\
>  +	DEFINE_WAIT(__wait);						\
>  +									\
>  +	for (;;) {							\
>  +		prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);	\
>  +		if (condition)						\
>  +			break;						\
>  +		cmd1;							\
>  +		schedule();						\
>  +		cmd2;							\
>  +	}								\
>  +	finish_wait(&wq, &__wait);					\
>  +} while (0)

Ideally we'd write the new thing like:

#define __wait_event_cmd(wq, condition, cmd1, cmd2) 			\
	(void)___wait_event(wq, condition, TASK_UNINTERRUPTIBLE, 0, 0,	\
			    cmd1; schedule(); cmd2)

Re: linux-next: manual merge of the tip tree

[Peter Zijlstra]

On Wed, Oct 16, 2013 at 10:51:15PM +0200, Thierry Reding wrote:
> On Wed, Oct 16, 2013 at 10:35:06PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 17, 2013 at 07:31:00AM +1100, NeilBrown wrote:
> > > It seems to have moved to 
> > >   git://gitorious.org/thierryreding/linux-next.git
> > 
> > Uhm.. what happened to sfr and why would we trust gitorious?
> 
> sfr is on vacation. Back at the time when Mark Brown and I volunteered
> to continue doing the linux-next trees in Stephen's absence I didn't
> have a kernel.org account. Also we decided rather late that we wanted to
> do this so there was no time to set things up properly. We had to make
> do with what we had.
> 
> Today's next-20131016 tag is signed with my GPG key that I use for my
> kernel.org account as well, so that should make it about equally trust-
> worthy as anything I'd be pushing to kernel.org.

Fair enough; and thanks for doing this.

Re: linux-next: manual merge of the tip tree

[Peter Zijlstra]

Hey Neil;

it looks like its one of your patches isn't it?

http://www.spinics.net/lists/raid/msg44100.html
http://www.spinics.net/lists/raid/msg44101.html

Given that I can't find them in a lkml archive means nobody's ever seen
those patches.

Anyway; has that 3/3 patch ever been ran with lockdep enabled? 

Stuff like:

+	for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
+		spin_lock_init(conf->hash_locks + i);

And:

+static void __lock_all_hash_locks(struct r5conf *conf)
+{
+	int i;
+	for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
+		spin_lock(conf->hash_locks + i);
+}

Tends to complain real loud.

This leaves one to wonder... 
  'fancy' locking scheme:1, validation effort:0

Re: linux-next: manual merge of the tip tree

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

On Wed, Oct 16, 2013 at 10:35:06PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 17, 2013 at 07:31:00AM +1100, NeilBrown wrote:
> > It seems to have moved to 
> >   git://gitorious.org/thierryreding/linux-next.git
> 
> Uhm.. what happened to sfr and why would we trust gitorious?

sfr is on vacation. Back at the time when Mark Brown and I volunteered
to continue doing the linux-next trees in Stephen's absence I didn't
have a kernel.org account. Also we decided rather late that we wanted to
do this so there was no time to set things up properly. We had to make
do with what we had.

Today's next-20131016 tag is signed with my GPG key that I use for my
kernel.org account as well, so that should make it about equally trust-
worthy as anything I'd be pushing to kernel.org.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the tip tree

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

On Wed, Oct 16, 2013 at 10:06:45PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got a conflict in
> > 
> > 	include/linux/wait.h
> > 
> > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > (sched/wait: Clean up wait.h details a bit).
> 
> Gargh, where did that come from?!

FWIW, commit 1ab2460 came in through Neil's md tree.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the tip tree

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

On Wed, Oct 16, 2013 at 10:14:10PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 16, 2013 at 10:06:45PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > > Today's linux-next merge of the tip tree got a conflict in
> > > 
> > > 	include/linux/wait.h
> > > 
> > > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > > (sched/wait: Clean up wait.h details a bit).
> > 
> > Gargh, where did that come from?!
> 
> Also, wth does that live?
> 
> 
> # git show 1ab2460
> fatal: ambiguous argument '1ab2460': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
> # git remote show next
> * remote next
>   Fetch URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> 
> And I made sure to update the remote.

Mark and I use this repository as a temporary location:

	git://gitorious.org/thierryreding/linux-next.git

If we ever decide to do this again when Stephen's on vacation, we should
try to get shared access setup for the kernel.org repository. Providing
temporary service was a spontaneous decision, so we didn't prepare very
well. Sorry for the inconvenience.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the tip tree

[Peter Zijlstra]

On Thu, Oct 17, 2013 at 07:31:00AM +1100, NeilBrown wrote:
> It seems to have moved to 
>   git://gitorious.org/thierryreding/linux-next.git

Uhm.. what happened to sfr and why would we trust gitorious?

Re: linux-next: manual merge of the tip tree

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Wed, 16 Oct 2013 22:14:10 +0200 Peter Zijlstra <peterz@infradead.org>
wrote:

> On Wed, Oct 16, 2013 at 10:06:45PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > > Today's linux-next merge of the tip tree got a conflict in
> > > 
> > > 	include/linux/wait.h
> > > 
> > > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > > (sched/wait: Clean up wait.h details a bit).
> > 
> > Gargh, where did that come from?!
> 
> Also, wth does that live?
> 
> 
> # git show 1ab2460
> fatal: ambiguous argument '1ab2460': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
> # git remote show next
> * remote next
>   Fetch URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> 
> And I made sure to update the remote.
> --
> 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/

It seems to have moved to 
  git://gitorious.org/thierryreding/linux-next.git

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: linux-next: manual merge of the tip tree

[Peter Zijlstra]

On Wed, Oct 16, 2013 at 10:06:45PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got a conflict in
> > 
> > 	include/linux/wait.h
> > 
> > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > (sched/wait: Clean up wait.h details a bit).
> 
> Gargh, where did that come from?!

Also, wth does that live?


# git show 1ab2460
fatal: ambiguous argument '1ab2460': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
# git remote show next
* remote next
  Fetch URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

And I made sure to update the remote.

Re: linux-next: manual merge of the tip tree

[Peter Zijlstra]

On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> Today's linux-next merge of the tip tree got a conflict in
> 
> 	include/linux/wait.h
> 
> caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> (sched/wait: Clean up wait.h details a bit).

Gargh, where did that come from?!

linux-next: manual merge of the tip tree

[Thierry Reding]

Today's linux-next merge of the tip tree got a conflict in

	include/linux/wait.h

caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
(sched/wait: Clean up wait.h details a bit).

I've cleaned it up (see below). Please verify that the resolution looks
good.

Thanks,
Thierry
---
diff --cc include/linux/wait.h
index d9eff54,a2726c7..0395985
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@@ -253,59 -275,9 +275,45 @@@ do {									
  	__ret;								\
  })
  
 +#define __wait_event_cmd(wq, condition, cmd1, cmd2)			\
 +do {									\
 +	DEFINE_WAIT(__wait);						\
 +									\
 +	for (;;) {							\
 +		prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);	\
 +		if (condition)						\
 +			break;						\
 +		cmd1;							\
 +		schedule();						\
 +		cmd2;							\
 +	}								\
 +	finish_wait(&wq, &__wait);					\
 +} while (0)
 +
 +/**
 + * wait_event_cmd - sleep until a condition gets true
 + * @wq: the waitqueue to wait on
 + * @condition: a C expression for the event to wait for
 + * cmd1: the command will be executed before sleep
 + * cmd2: the command will be executed after sleep
 + *
 + * The process is put to sleep (TASK_UNINTERRUPTIBLE) until the
 + * @condition evaluates to true. The @condition is checked each time
 + * the waitqueue @wq is woken up.
 + *
 + * wake_up() has to be called after changing any variable that could
 + * change the result of the wait condition.
 + */
 +#define wait_event_cmd(wq, condition, cmd1, cmd2)			\
 +do {									\
 +	if (condition)							\
 +		break;							\
 +	__wait_event_cmd(wq, condition, cmd1, cmd2);			\
 +} while (0)
 +
- #define __wait_event_interruptible(wq, condition, ret)			\
- do {									\
- 	DEFINE_WAIT(__wait);						\
- 									\
- 	for (;;) {							\
- 		prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE);	\
- 		if (condition)						\
- 			break;						\
- 		if (!signal_pending(current)) {				\
- 			schedule();					\
- 			continue;					\
- 		}							\
- 		ret = -ERESTARTSYS;					\
- 		break;							\
- 	}								\
- 	finish_wait(&wq, &__wait);					\
- } while (0)
+ #define __wait_event_interruptible(wq, condition)			\
+ 	___wait_event(wq, condition, TASK_INTERRUPTIBLE, 0, 0,		\
+ 		      schedule())
  
  /**
   * wait_event_interruptible - sleep until a condition gets true

linux-next: manual merge of the tip tree

[Thierry Reding]

Today's linux-next merge of the tip tree got conflicts in

	arch/h8300/include/asm/Kbuild

I just removed the file.

Thanks,
Thierry