Linux 2.6.35

Linux 2.6.35

[Linus Torvalds]

So I said -rc6 would likely be the last -rc, and nothing happened to
change my mind. I'd always be happier if it had been an even quieter
week, but the appended Shortlog of changes since rc6 doesn't contain
anything earthshaking, and I don't think we'd have been any better off
by another rc, and waiting one more week. So 2.6.35 is out, go check
it out.

This may have been a fairly odd release cycle with my rather strict
-rc rules before -rc3, but on the whole I think I liked it, and it
seems to have worked out ok. I relaxed my extreme stance after getting
back from vacation, so the latter half of the rc series was more
normal. But even then I got the feeling that people were perhaps a bit
more aware of the whole "regression fixes only" model, which is all
good. It's a bit hard to judge, but there are some numbers to back it
up: in the 2.6.34 release, there were 3800 commits after -rc1, but in
the current 35 release cycle we had less than 2000.

Now, admittedly 34 was worse than average in that respect (3800
commits is a _lot_ of work after -rc1), but git history says that at
least going back to 2.6.24, we've never had less than 2000 commits
after -rc1 before now. They tend to be in the 2700-3200 commit range.
So I do think we really did have a lot less churn than usual
post-merge-window. And that's good.

So I'd like to try to repeat the experiment for the next release
cycle, and be pretty hardnosed about taking patches and git pull
requests after the merge window closes.

Talking about the next merge window: Andrew Morton was pretty unhappy
with the stability of linux-next at least a couple of weeks ago. It's
what he bases his -mm trees on, and so an unstable linux-next makes it
hard for Andrew to get his work done. It also makes me worried,
because a lot of people seem to think that "it's been in linux-next
for several months" means that something can and should be merged. And
if linux-next ends up being really flaky, that clearly cannot be the
case.

So guys - please don't treat linux-next as a dumping ground. Things
that go in there should be more or less ready for merging (with an
emphasis on "more"), and we need to keep that tree in working order.
If you're nervous about the stability of your work, you should just
admit that it's not ready to be merged, shouldn't go in the next
release cycle, and shouldn't be in linux-next yet and make life harder
for people like Andrew - or for the other more careful linux-next
submitters.

On a slightly happier note: one thing I do hope we can merge in the
upcoming merge window is Nick Piggin's cool VFS scalability series.
I've been using it on my own machine, and gone through all the commits
(not that I shouldn't go through some of them some more), and am
personally really excited about it. It's seldom we see major
performance improvements in core code that are quite that noticeable,
and Nick's whole RCU pathname lookup in particular just tickles me
pink.

Anything else? I'm sure there's tons of things I should say about what
went into 2.6.35, but as usual there are already better writeups about
what has changed. Things like the kernelnewbies pages etc. So head off
to

  http://kernelnewbies.org/Linux_2_6_35

for some overviews of the things that changed this time around. Or
just download the kernel from the regular places, and give it a test.

                       Linus

---
Adam Jackson (2):
      drm/i915: Make G4X-style PLL search more permissive
      drm/edid: Fix the HDTV hack sync adjustment

Adam Lackorzynski (1):
      x86, i8259: Only register sysdev if we have a real 8259 PIC

Alex Chiang (1):
      ACPI: processor: fix processor_physically_present on UP

Alexey Shvetsov (1):
      wimax/i2400m: Add PID & VID for Intel WiMAX 6250

Andre Osterhues (1):
      ecryptfs: Bugfix for error related to ecryptfs_hash_buckets

Andrea Shepard (1):
      net: Fix corruption of skb csum field in pskb_expand_head() of
net/core/skbuff.c

Andrej Gelenberg (1):
      [CPUFREQ] revert "[CPUFREQ] remove rwsem lock from
CPUFREQ_GOV_STOP call (second call site)"

Andrew Bird (1):
      USB: New PIDs for Qualcomm gobi 2000 (qcserial)

Andy Gospodarek (1):
      ixgbe/igb: catch invalid VF settings

Anton Blanchard (2):
      powerpc/mm: Handle hypervisor pte insert failure in __hash_page_huge
      [SCSI] ibmvscsi: Fix oops when an interrupt is pending during probe

Anton Vorontsov (1):
      edac: mpc85xx: fix coldplug/hotplug module autoloading

Anuj Aggarwal (1):
      regulator: tps6507x: allow driver to use DEFDCDC{2,3}_HIGH register

Arnaldo Carvalho de Melo (1):
      perf annotate: Fix handling of goto labels that are valid hex numbers

Avi Kivity (1):
      KVM: Use kmalloc() instead of vmalloc() for KVM_[GS]ET_MSR

Axel Lin (2):
      ab3100: fix off-by-one value range checking for voltage selector
      wm8350-regulator: fix wm8350_register_regulator error handling

Ben Greear (1):
      net: dev_forward_skb should call nf_reset

Ben Hutchings (1):
      MIPS: Set io_map_base for several PCI bridges lacking it

Benjamin Herrenschmidt (4):
      powerpc/mm: Move around testing of _PAGE_PRESENT in hash code
      powerpc/mm: Fix bugs in huge page hashing
      powerpc/mm: Add some debug output when hash insertion fails
      powerpc: Fix erroneous lmb->memblock conversions

Bob Copeland (1):
      USB: usb-storage: fix initializations of urb fields

Borislav Petkov (1):
      [CPUFREQ] powernow-k8: Limit Pstate transition latency check

Breno Leitao (1):
      s2io: fixing DBG_PRINT() macro

Brian Haley (1):
      ipv6: Don't add routes to ipv6 disabled interfaces.

Bruno Randolf (1):
      MIPS: MTX-1: Fix PCI on the MeshCube and related boards

Catalin Marinas (3):
      ARM: 6271/1: Introduce *_relaxed() I/O accessors
      ARM: 6272/1: Convert L2x0 to use the IO relaxed operations
      ARM: 6273/1: Add barriers to the I/O accessors if ARM_DMA_MEM_BUFFERABLE

Chris Wilson (4):
      drm/i915: Explosion following OOM in do_execbuffer.
      drm/i915: Clear any existing dither mode prior to enabling
spatial dithering
      drm/i915: Use the correct scanout alignment for fbcon.
      drm/i915: Fix panel fitting regression since 734b4157

Christof Schmitt (2):
      [SCSI] zfcp: Do not wait for SBALs on stopped queue
      [SCSI] zfcp: Update status read mempool

Colin Leitner (1):
      USB: ftdi_sio: support for Signalyzer tools based on FTDI chips

Conny Seidel (1):
      perf tools: Fix fallback to cplus_demangle() when bfd_demangle()
is not available

Corey Minyard (1):
      USB: FTDI: Add support for the RT System VX-7 radio programming cable

Dan Carpenter (1):
      nfs: include space for the NUL in root path

Daniel J Blueman (3):
      quiesce EDAC initialisation on desktop/mobile i7
      [CPUFREQ] fix double freeing in error path of pcc-cpufreq
      drm/radeon/kms: fix radeon mid power profile reporting

David Daney (3):
      MIPS: "Fix" useless 'init_vdso successfully' message.
      MIPS: Make init_vdso a subsys_initcall.
      MIPS: Quit using undefined behavior of ADDU in 64-bit atomic operations.

David Howells (3):
      CRED: Fix get_task_cred() and task_state() to not resurrect dead
credentials
      CRED: Fix __task_cred()'s lockdep check and banner comment
      CIFS: Remove __exit mark from cifs_exit_dns_resolver()

David S. Miller (1):
      net: Fix skb_copy_expand() handling of ->csum_start

David VomLehn (1):
      MIPS: PowerTV: Move register setup to before reading registers.

Dennis Jansen (1):
      USB: option: Add support for AMOI Skypephone S2

Dmitry Torokhov (1):
      Input: RX51 keymap - fix recent compile breakage

Eric Miao (3):
      [ARM] pxa/corgi: fix MMC/SD card detection failure
      [ARM] pxa: fix incorrect order of AC97 reset pin configs
      [ARM] pxa: fix incorrect CONFIG_CPU_PXA27x to CONFIG_PXA27x

Eric W. Biederman (4):
      Driver-core: Always create class directories for classses that
support namespaces.
      sysfs: Don't allow the creation of symlinks we can't remove
      sysfs: sysfs_delete_link handle symlinks from untagged to tagged
directories.
      sysfs: allow creating symlinks from untagged to tagged directories

Felipe Balbi (1):
      USB: musb: tusb6010: fix compile error with n8x0_defconfig

Florian Fainelli (1):
      MIPS: BCM63xx: Prevent second enet registration on BCM6338

Frederic Weisbecker (1):
      perf: Fix various display bugs with parent filtering

Gary King (1):
      ARM: 6279/1: highmem: fix SMP preemption bug in kmap_high_l1_vipt

Greg Edwards (1):
      bonding: set device in RLB ARP packet handler

Gui Jianfeng (1):
      perf symbols: Fix directory descriptor leaking

Heiko Carstens (1):
      [S390] Fix IRQ tracing in case of PER

Herbert Xu (1):
      macvtap: Limit packet queue length

Hugh Dickins (1):
      mm: fix ia64 crash when gcore reads gate area

Jason Baron (1):
      dynamic debug: move ddebug_remove_module() down into free_module()

Jason Wessel (1):
      x86,kgdb: Fix hw breakpoint regression

Jeremy Kerr (5):
      ARM: 6258/1: arm/h720x: fix debug macro compilation failure
      ARM: 6259/1: arm/ns9xxx: fix debug macro compilation failure
      ARM: 6260/1: arm/plat-spear: fix debug macro compilation failure
      ARM: 6261/1: arm/shark: fix debug macro compilation failure
      ARM: 6262/1: arm/clps711x: fix debug macro compilation failure

Jesse Barnes (8):
      drm/i915: handle shared framebuffers when flipping
      drm/i915: add PANEL_UNLOCK_REGS definition
      drm/i915: make sure eDP panel is turned on
      drm/i915: disable FBC when more than one pipe is active
      drm/i915: don't free non-existent compressed llb on ILK+
      drm/i915: fix deadlock in fb teardown
      drm/i915: add pipe A force quirks to i915 driver
      drm/i915: make sure we shut off the panel in eDP configs

John W. Linville (1):
      wireless: use netif_rx_ni in ieee80211_send_layer2_update

Jon Povey (1):
      gpio: fix spurious printk when freeing a gpio

Julia Lawall (1):
      SA1111: Eliminate use after free

KOSAKI Motohiro (1):
      ACPI: fix unused function warning

Kumar Gala (1):
      powerpc/kexec: Fix boundary case for book-e kexec memory limits

Latchesar Ionkov (1):
      9p: Pass the correct end of buffer to p9stat_read

Len Brown (3):
      ACPI: handle systems which asynchoronously enable ACPI mode
      ACPI: skip checking BM_STS if the BIOS doesn't ask for it
      ACPI: create "processor.bm_check_disable" boot param

Linus Torvalds (1):
      Linux 2.6.35

Magnus Damm (1):
      ARM: 6270/1: clean files in arch/arm/boot/compressed/

Marek Vasut (2):
      [ARM] pxa: cpufreq-pxa2xx: fix DRI recomputation routine
      [ARM] pxa: fix frequency scaling for pcmcia/pxa2xx_base

Martin Schwidefsky (1):
      [S390] etr: fix clock synchronization race

Matthew Garrett (2):
      [CPUFREQ] pcc driver should check for pcch method before calling _OSC
      [CPUFREQ] Fix PCC driver error path

Michael S. Tsirkin (2):
      tun: avoid BUG, dump packet on GSO errors
      virtio: fix oops on OOM

Michal Marek (1):
      kbuild: Fix make rpm

Michał Górny (1):
      kbuild: Make the setlocalversion script POSIX-compliant

Ming Lei (1):
      ath9k: fix dma direction for map/unmap in ath_rx_tasklet

Nik A. Melchior (1):
      ACPI video: fix string mismatch for Sony SR290 laptop

Oliver Neukum (2):
      USB: sisusbvga: Fix for USB 3.0
      USB: add quirk for Broadcom BT dongle

Ondrej Zary (2):
      cyber2000fb: fix machine hang on module load
      cyber2000fb: fix console in truecolor modes

Paul Mortier (1):
      USB: adds Artisman USB dongle to list of quirky devices

Peter Huewe (2):
      ds2782_battery: Rename get_current to fix build failure / name conflict
      serial: fix rs485 for atmel_serial on avr32

Peter Zijlstra (1):
      perf, powerpc: Use perf_sample_data_init() for the FSL code

Przemo Firszt (1):
      USB: Expose vendor-specific ACM channel on Nokia 5230

Rabin Vincent (1):
      ARM: 6275/1: ux500: don't use writeb() in uncompress.h

Rafael J. Wysocki (1):
      ACPI / Sleep: Allow the NVS saving to be skipped during suspend to RAM

Rajiv Andrade (1):
      tpm_tis: fix subsequent suspend failures

Ralf Baechle (7):
      VIDEO. gbefb: Fix section mismatches.
      NET: declance: Fix section mismatches
      VIDEO: PMAG-BA: Fix section mismatch
      VIDEO: PMAGB-B: Fix section mismatch
      VIDEO: Au1100fb: Fix section mismatch
      SOUND: Au1000: Fix section mismatch
      MIPS: N32: Define getdents64.

Robert P. J. Day (1):
      ceph: Correct obvious typo of Kconfig variable "CRYPTO_AES"

Rudolf Marek (1):
      drivers/rtc/rtc-rx8581.c: fix setdatetime

Russell King (3):
      ARM: Fix csum_partial_copy_from_user()
      ARM: Add barriers to io{read,write}{8,16,32} accessors as well
      ARM: Fix Versatile/Realview/VExpress MMC card detection sense

Sage Weil (5):
      ceph: avoid dcache readdir for snapdir
      ceph: fix d_release dop for snapdir, snapped dentries
      ceph: fix pg_mapping leak on pg_temp updates
      ceph: fix leak of dentry in ceph_init_dentry() error path
      ceph: fix dentry lease release

Sam Ravnborg (2):
      tracing: Properly align linker defined symbols
      vmlinux.lds: fix .data..init_task output section (fix popwerpc boot)

Sarah Sharp (4):
      USB: xHCI: Fix another bug in link TRB activation change.
      USB: Fix USB3.0 Port Speed Downgrade after port reset
      USB: xhci: Set EP0 dequeue ptr after reset of configured device.
      USB: xhci: Set Mult field in endpoint context correctly.

Sekhar Nori (1):
      davinci: da850/omap-l138 evm: account for DEFDCDC{2,3} being tied high

Stefano Stabellini (1):
      x86: Do not try to disable hpet if it hasn't been initialized before

Stephen Boyd (1):
      nconfig: Fix segfault when help contains special characters

Steven Whitehouse (1):
      GFS2: Use kmalloc when possible for ->readdir()

Swen Schillig (1):
      [SCSI] zfcp: Fix check whether unchained ct_els is possible

Takashi Iwai (4):
      ALSA: hda - Fix pin-detection of Nvidia HDMI
      ALSA: hda - Don't register beep input device when no beep is available
      ALSA: hda - Assume PC-beep as default for Realtek
      ALSA: hda - Add a PC-beep workaround for ASUS P5-V

Thomas Bächler (1):
      gpu/drm/i915: Add a blacklist to omit modeset on LID open

Tim Gardner (1):
      agp/intel: Use the correct mask to detect i830 aperture size.

Trond Myklebust (3):
      NFS: kswapd must not block in nfs_release_page
      NFS: Ensure that writepage respects the nonblock flag
      NFS: Fix a typo in include/linux/nfs_fs.h

Uwe Kleine-König (2):
      ARM: 6263/1: ns9xxx: fix FTBFS for zImage
      ARM: 6265/1: kirkwood: move qnap_tsx1x_register_flash() to .init.text

Vladimir Zapolskiy (1):
      USB: s3c2410_udc: be aware of connected gadget driver

Vladislav Zolotarov (3):
      bnx2x: Protect a SM state change
      bnx2x: Protect statistics ramrod and sequence number
      bnx2x: Advance a module version

Wayne Boyer (1):
      [SCSI] ipr: fix resource path display and formatting

Wim Van Sebroeck (1):
      watchdog: update MAINTAINERS entry

Wolfgang Grandegger (1):
      MIPS: Alchemy: Define eth platform devices in the correct order

Xiao Guangrong (1):
      KVM: MMU: fix conflict access permissions in direct sp

Xiaotian Feng (1):
      [CPUFREQ] fix memory leak in cpufreq_add_dev

Yehuda Sadeh (1):
      ceph: use complete_all and wake_up_all

Zhang Rui (1):
      ACPI battery: don't invoke power_supply_changed twice when
battery is hot-added

august huber (1):
      USB: Add PID for Sierra 250U to drivers/usb/serial/sierra.c

pieterg (1):
      [ARM] pxa/colibri-pxa300: fix AC97 init

stephen hemminger (1):
      net sched: fix race in mirred device removal

wanzongshun (2):
      ARM: 6230/1: fix nuc900 touchscreen clk definition bug
      ARM: 6233/1: Delete a wrong redundant right parenthesis

Ömer Sezgin Ugurlu (1):
      USB: option: add support for 1da5:4518

Re: Linux 2.6.35

[Stephen Rothwell]

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

Hi all,

On Sun, 1 Aug 2010 16:52:42 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On a slightly happier note: one thing I do hope we can merge in the
> upcoming merge window is Nick Piggin's cool VFS scalability series.
> I've been using it on my own machine, and gone through all the commits
> (not that I shouldn't go through some of them some more), and am
> personally really excited about it. It's seldom we see major
> performance improvements in core code that are quite that noticeable,
> and Nick's whole RCU pathname lookup in particular just tickles me
> pink.

To that end, Nick, can you please submit that tree for inclusion in
linux-next in case there are some interactions with some of the other
stuff there?  (or send it all to Al, instead (or both), I guess.)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: Linux 2.6.35

[Nick Piggin]

On Mon, Aug 02, 2010 at 10:32:04AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Sun, 1 Aug 2010 16:52:42 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> > On a slightly happier note: one thing I do hope we can merge in the
> > upcoming merge window is Nick Piggin's cool VFS scalability series.
> > I've been using it on my own machine, and gone through all the commits
> > (not that I shouldn't go through some of them some more), and am
> > personally really excited about it. It's seldom we see major
> > performance improvements in core code that are quite that noticeable,
> > and Nick's whole RCU pathname lookup in particular just tickles me
> > pink.
> 
> To that end, Nick, can you please submit that tree for inclusion in
> linux-next in case there are some interactions with some of the other
> stuff there?  (or send it all to Al, instead (or both), I guess.)

Hi Stephen,

I will work something out with Al and try to have something in
linux-next ASAP.

Re: Linux 2.6.35

[Stephen Rothwell]

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

Hi Nick,

On Mon, 2 Aug 2010 18:14:22 +1000 Nick Piggin <npiggin@suse.de> wrote:
>
> I will work something out with Al and try to have something in
> linux-next ASAP.

OK, great.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: Linux 2.6.35

[Dave Chinner]

On Sun, Aug 01, 2010 at 04:52:42PM -0700, Linus Torvalds wrote:
> On a slightly happier note: one thing I do hope we can merge in the
> upcoming merge window is Nick Piggin's cool VFS scalability series.
> I've been using it on my own machine, and gone through all the commits
> (not that I shouldn't go through some of them some more), and am
> personally really excited about it. It's seldom we see major
> performance improvements in core code that are quite that noticeable,
> and Nick's whole RCU pathname lookup in particular just tickles me
> pink.

There hasn't been nearly enough review or testing of this patch
series yet.  Before a merge, it needs to be split up in smaller,
more digestable chunks for more comprehensive review, regression
testing and behavioural analysis.

There's probably only a handful of people who have done any testing
on the patchset so far, and given the widespread changes it needs a
lot more testing than this before we should consider merging any of
it.

I really want to see this move forward too, but it changes lots of
critical infrastructure in subtle ways and so, IMO, this is not
a patchset we should be gung-ho about.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: Linux 2.6.35

[Linus Torvalds]

On Sun, Aug 1, 2010 at 7:33 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> There hasn't been nearly enough review or testing of this patch
> series yet.  Before a merge, it needs to be split up in smaller,
> more digestable chunks for more comprehensive review, regression
> testing and behavioural analysis.

I dunno. We merge _way_ scarier things in the VM and the block layer,
for much less actual upside, and with less review.

The RCU pathname lookup has some rather impressive performance
upsides, and I agree that it would be good to get a lot of review and
testing, but the latter isn't going to happen without it being
mainlined, and the former is sadly lacking. The person I'd like most
to review it is Al, but anybody in the filesystem world should
basically see it as a #1 priority, because unlike all the masturbatory
patches like xstat() that add new functionality that nobody will
likely ever use, Nick's patchseries improves on the thing that
everybody uses heavily every day without even thinking about it.

Is it tough to review? Yes. It's core code, not just some random
addition that adds a new feature and doesn't impact any old code. But
that's also the thing that makes it meaningful, and makes me think it
should get merged _much_ more eagerly than most code we ever see.

                           Linus

Re: Linux 2.6.35

[Dave Chinner]

On Sun, Aug 01, 2010 at 07:50:02PM -0700, Linus Torvalds wrote:
> On Sun, Aug 1, 2010 at 7:33 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > There hasn't been nearly enough review or testing of this patch
> > series yet.  Before a merge, it needs to be split up in smaller,
> > more digestable chunks for more comprehensive review, regression
> > testing and behavioural analysis.
> 
> I dunno. We merge _way_ scarier things in the VM and the block layer,
> for much less actual upside, and with less review.

Scary stuff outside of direct VFS/FS interfaces is generally hidden
from me by my +6 Blinkers of Blissful Ignorance. I make the
assumption that the experts involved know the risks and have weighed
them up appropriately. ;)

> The RCU pathname lookup has some rather impressive performance
> upsides, and I agree that it would be good to get a lot of review and
> testing, but the latter isn't going to happen without it being
> mainlined, and the former is sadly lacking. The person I'd like most
> to review it is Al,

Most definitely.

> but anybody in the filesystem world should
> basically see it as a #1 priority,

Agreed - I've actually looked at every patch, commented on some
of the more questionable things, got quoted by LWN for saying that
it "fell off the locking cliff", have run benchmarks on it and sent
patches fixing bugs back to Nick.

It's just really hard to digest it all in one lump and core VFS
changes on this scale scare me....

> because unlike all the masturbatory
> patches like xstat() that add new functionality that nobody will
> likely ever use, Nick's patchseries improves on the thing that
> everybody uses heavily every day without even thinking about it.
> 
> Is it tough to review? Yes. It's core code, not just some random
> addition that adds a new feature and doesn't impact any old code. But
> that's also the thing that makes it meaningful, and makes me think it
> should get merged _much_ more eagerly than most code we ever see.

I agree with you for the pure locking changes.

But for the bits that change writeback, LRU ordering and reclaim
calculations the benefits are not quite so obvious, nor is the
correctness of the code/behaviour quite so provably correct.  Maybe
I'm being a bit too paranoid, but generally it pays to be a bit
conservative as a filesystem developer because the cost of screwing
up can be pretty high...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: Linux 2.6.35

[Nick Piggin]

On Mon, Aug 02, 2010 at 03:58:34PM +1000, Dave Chinner wrote:
> On Sun, Aug 01, 2010 at 07:50:02PM -0700, Linus Torvalds wrote:
> > On Sun, Aug 1, 2010 at 7:33 PM, Dave Chinner <david@fromorbit.com> wrote:
> > >
> > > There hasn't been nearly enough review or testing of this patch
> > > series yet.  Before a merge, it needs to be split up in smaller,
> > > more digestable chunks for more comprehensive review, regression
> > > testing and behavioural analysis.

BTW. it has in fact had quite a bit of testing in earlier form in the
-rt tree for a long time, and several fixes come from there. And good
performance results there too.


> > I dunno. We merge _way_ scarier things in the VM and the block layer,
> > for much less actual upside, and with less review.
> 
> Scary stuff outside of direct VFS/FS interfaces is generally hidden
> from me by my +6 Blinkers of Blissful Ignorance. I make the
> assumption that the experts involved know the risks and have weighed
> them up appropriately. ;)
> 
> > The RCU pathname lookup has some rather impressive performance
> > upsides, and I agree that it would be good to get a lot of review and
> > testing, but the latter isn't going to happen without it being
> > mainlined, and the former is sadly lacking. The person I'd like most
> > to review it is Al,
> 
> Most definitely.

I hate to say but I would like to see it mature for another release. It
should also clash a bit with Al's recent inode work that he'll want to
push.

What I can do is send some of the ground work patches this time around,
put the tree into linux-next, and put reviewers on notice.

I think it is all conceptually sound, but it will inevitably have some
bugs left to shake out, and things to be fixed on the review side. I
don't anticipate a problem that could not be fixed in the release cycle,
but I think aiming for post 2.6.36 is a bit fairer for vfs guys,
honestly. LSF is next week too, so most of them will be busy with travel
and such. But I do hope to discuss the vfs-scale patches there.


> > but anybody in the filesystem world should
> > basically see it as a #1 priority,
> 
> Agreed - I've actually looked at every patch, commented on some
> of the more questionable things, got quoted by LWN for saying that
> it "fell off the locking cliff", have run benchmarks on it and sent
> patches fixing bugs back to Nick.
> 
> It's just really hard to digest it all in one lump and core VFS
> changes on this scale scare me....

For filesystems developers, the dcache and inode locking changes
should be more or less just following simple steps as shown in the
patch series. If they're not abusing dcache_lock (and most except
autofs4 are not), then it should not be a big deal.

There are a couple of locking constraints changed at the API level,
but I didn't run into any problems there yet. It should be all
documented in Documentation/filesystems/* although I need to run a
few more passes over the series to ensure I caught everything.


> > because unlike all the masturbatory
> > patches like xstat() that add new functionality that nobody will
> > likely ever use, Nick's patchseries improves on the thing that
> > everybody uses heavily every day without even thinking about it.
> > 
> > Is it tough to review? Yes. It's core code, not just some random
> > addition that adds a new feature and doesn't impact any old code. But
> > that's also the thing that makes it meaningful, and makes me think it
> > should get merged _much_ more eagerly than most code we ever see.
> 
> I agree with you for the pure locking changes.
> 
> But for the bits that change writeback, LRU ordering and reclaim
> calculations the benefits are not quite so obvious, nor is the
> correctness of the code/behaviour quite so provably correct.  Maybe
> I'm being a bit too paranoid, but generally it pays to be a bit
> conservative as a filesystem developer because the cost of screwing
> up can be pretty high...

Writeback shouldn't be changed. LRU ordering is changed for 2
reasons. Firstly, to make things per-zone instead of global. This
basically fits our whole reclaim model much better, although it
will inevitably cause some random little changes but I think it
is agreed this is a good thing (memory shortage in one zone or
node does not require global shrinkings, NUMA level parallelism
of reclaim.)

The other thing is converting the last few dcache refcounting, and
all of inode refcounting over to this "lazy LRU" model. This can
have a bigger impact, but it really reduces locking on the per-zone
lists, so it definitely helps speed and scalability of non-reclaim
fastpaths. I'm up for changing this if numbers show it hurts, it
would be rather easy to do, but in comparison to the overall
patchset, it would rate as a minor tweak :)

Re: Linux 2.6.35

[Christoph Hellwig]

On Mon, Aug 02, 2010 at 05:55:37PM +1000, Nick Piggin wrote:
> I hate to say but I would like to see it mature for another release. It
> should also clash a bit with Al's recent inode work that he'll want to
> push.
> 
> What I can do is send some of the ground work patches this time around,
> put the tree into linux-next, and put reviewers on notice.
> 
> I think it is all conceptually sound, but it will inevitably have some
> bugs left to shake out, and things to be fixed on the review side. I
> don't anticipate a problem that could not be fixed in the release cycle,
> but I think aiming for post 2.6.36 is a bit fairer for vfs guys,
> honestly. LSF is next week too, so most of them will be busy with travel
> and such. But I do hope to discuss the vfs-scale patches there.

What I'm most concerned bit merging everything in one go.  It's a huge
series and I'd rather see it start going in in batches over multiple
kernel releases.

Things like the fs_struct spinlock and some other preparatory patches
should be ver easily to do for 2.6.36.  Scaling the files and vfsmount
locks should also be easily doable, but we need to sort out the struct
file growth in the later.  We really can't grow struct file by two
pointers as that would have devasting effects on various workloads.

What follows after that is the dcache_lock scaling which to seems the
most immature bit of the series, and the one that showed by far the
most problems in -RT.  I'm very much dead set against merging that in
.36.  I'd much rather see the inode_lock scaling or the lockless path
walk going in before, but I haven't checked how complicated the
reordering would be.  The lockless path walk also is only rather
theoretically useful until we do ACL checks lockless as we're having
ACLs enabled pretty much everywhere at least in the distros.

The per-zone shrinkers are another thing that's not directly related,
I think they need a lot more discussion with the VM folks, and
integrating with Dave's work in that area.

Re: Linux 2.6.35

[KOSAKI Motohiro]

> The per-zone shrinkers are another thing that's not directly related,
> I think they need a lot more discussion with the VM folks, and
> integrating with Dave's work in that area.

per-zone shrinkers don't cause so much impact to VM design except zone
reclaim feature. So, if FS folks think it's ok, I'm not against this at all.

btw, however, I haven't review such patch series in the detail yet. so
perhaps I might post some bug fix later.

Re: Linux 2.6.35

[Christoph Hellwig]

On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote:
> .36.  I'd much rather see the inode_lock scaling or the lockless path
> walk going in before, but I haven't checked how complicated the
> reordering would be.  The lockless path walk also is only rather
> theoretically useful until we do ACL checks lockless as we're having
> ACLs enabled pretty much everywhere at least in the distros.

>From a quick look it seems like the inode_lock splitup can easily
be moved forward, and it would help us with doing some work on the
writeback side.  The problem is that it would need rebasing ontop
of both the vfs and writeback (aka block) trees.

Re: Linux 2.6.35

[Nick Piggin]

On Mon, Aug 02, 2010 at 05:05:42AM -0400, Christoph Hellwig wrote:
> On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote:
> > .36.  I'd much rather see the inode_lock scaling or the lockless path
> > walk going in before, but I haven't checked how complicated the
> > reordering would be.  The lockless path walk also is only rather
> > theoretically useful until we do ACL checks lockless as we're having
> > ACLs enabled pretty much everywhere at least in the distros.
> 
> >From a quick look it seems like the inode_lock splitup can easily
> be moved forward, and it would help us with doing some work on the
> writeback side.  The problem is that it would need rebasing ontop
> of both the vfs and writeback (aka block) trees.

inode_lock splitup is much simpler than dcache_lock, yes.

And I have to rebase it on the work currently queued for 2.6.35
anyway, so that's no problem. I can easily put it in front of
dcache_lock patches in the series (as I said, I've kept everything
independent and well split up).

I do want opinions on how to do the big-picture merge, though,
before I start moving things around. And obviously reviewing
each of the parts is more important at this point than exact
way to order the thing.

But even the inode_lock patches I am wary of merging in 2.6.36
without having much review or any linux-next / vfs-tree exposure.

Re: Linux 2.6.35

[Nick Piggin]

On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote:
> On Mon, Aug 02, 2010 at 05:55:37PM +1000, Nick Piggin wrote:
> > I hate to say but I would like to see it mature for another release. It
> > should also clash a bit with Al's recent inode work that he'll want to
> > push.
> > 
> > What I can do is send some of the ground work patches this time around,
> > put the tree into linux-next, and put reviewers on notice.
> > 
> > I think it is all conceptually sound, but it will inevitably have some
> > bugs left to shake out, and things to be fixed on the review side. I
> > don't anticipate a problem that could not be fixed in the release cycle,
> > but I think aiming for post 2.6.36 is a bit fairer for vfs guys,
> > honestly. LSF is next week too, so most of them will be busy with travel
> > and such. But I do hope to discuss the vfs-scale patches there.
> 
> What I'm most concerned bit merging everything in one go.  It's a huge
> series and I'd rather see it start going in in batches over multiple
> kernel releases.

One problem is that to win much benefit, several different aspects
must be scaled. If not, then you end up with more locks *and* still
have bouncing global cachelines. And filesystems will go through
multiple releases where locking changes are in flux. This is what
I'm concerned about.

I definitely have tried to keep everything as conceptually seperate
small chunks. But there is a real big-picture aspect that is required
to review it.

For example, you asked for just the locking split-up without any of
the per-hash-locks and per-cpu locks etc. That's fine for review, but
you cannot merge it because then you end up with N bouncing global
locks instead of 1. It also tends to be much uglier than a final
outcome because I have not applied any transformations to improve lock
orderings and reduce trylocking etc.


> Things like the fs_struct spinlock and some other preparatory patches
> should be ver easily to do for 2.6.36.  Scaling the files and vfsmount
> locks should also be easily doable, but we need to sort out the struct
> file growth in the later.  We really can't grow struct file by two
> pointers as that would have devasting effects on various workloads.

Strictly, it is a filesystem corruption bug-fix for the tty layer
and nothing to do with tty scaling patches.

I don't have the patience at the moment to sort through tty layer
crap, but whoever is maintaining that should. I could possibly come
back and look at it some point, but given your half-working patch
as a guide, I think someone who knows the code can fix it.


> What follows after that is the dcache_lock scaling which to seems the
> most immature bit of the series, and the one that showed by far the
> most problems in -RT.  I'm very much dead set against merging that in
> .36.

That's a fair point, I agree with. It needs most review.


>  I'd much rather see the inode_lock scaling or the lockless path
> walk going in before, but I haven't checked how complicated the
> reordering would be.

I would much prefer not to re-order it before either of inode or
dcache scaling patches. It would introduce a lot of churn and
locking is significantly changed.

It probably should be possible, although we would still get path
walk contention on dcache_lock, vfsmount_lock, and requires inode-RCU
(making inodes more expensive without being offset by any benefits of
inode scaling), and requires changes to filesystem dcache and inode
APIs.

I could work on re-ordering it certainly, but only if it is decided
that we definitely don't want dcache-scale or inode-scale patch sets
in the forseeable future. I think we definitely do want them, so I
find it hard to justify a big reordering.


>  The lockless path walk also is only rather
> theoretically useful until we do ACL checks lockless as we're having
> ACLs enabled pretty much everywhere at least in the distros.

True, it needs a last bit of work for permission checking. The 
conceptual idea and the bulk of the code I think is ready to review
though. ACLs should be just more of the same.


> The per-zone shrinkers are another thing that's not directly related,
> I think they need a lot more discussion with the VM folks, and
> integrating with Dave's work in that area.

Well I'm a VM folk :) Conceptually, there is no problems for MM
here. This is really the right way to drive reclaim from the MM
perspective (ie. per-zone). Of course I will work with Dave and
take suggestions on implementation.

It is directly related in that it is required to remove global lock and
global list scanning from vfs reclaim, which is something that we've
known and wanted for a long time.

On one hand, you might say I'm going overboard, but on another hand,
vfs really sucks on NUMA and SMP right now and it's only going to
get worse for "normal" (ie. not HPC) people.

Re: Linux 2.6.35

[Andi Kleen]

Dave Chinner <david@fromorbit.com> writes:

> On Sun, Aug 01, 2010 at 04:52:42PM -0700, Linus Torvalds wrote:
>> On a slightly happier note: one thing I do hope we can merge in the
>> upcoming merge window is Nick Piggin's cool VFS scalability series.
>> I've been using it on my own machine, and gone through all the commits
>> (not that I shouldn't go through some of them some more), and am
>> personally really excited about it. It's seldom we see major
>> performance improvements in core code that are quite that noticeable,
>> and Nick's whole RCU pathname lookup in particular just tickles me
>> pink.
>
> There hasn't been nearly enough review or testing of this patch
> series yet.  Before a merge, it needs to be split up in smaller,
> more digestable chunks for more comprehensive review, regression
> testing and behavioural analysis.

We started some testing of the VFS series on larger systems and so
far it looks all very good and the performance improvements are impressive
(but of course new bottlenecks are being exposed then)

The only snag found so far was that an ACL enabled file system
disables all the nice path walk improvements, so right now you
need to remount with noacl. I'm hoping this can be fixed
before a mainline release, otherwise I suspect it would disable
the improvements for lots of people (common distributions default
to acl on)

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Linux 2.6.35

[Nick Piggin]

On Tue, Aug 03, 2010 at 10:18:30AM +0200, Andi Kleen wrote:
> Dave Chinner <david@fromorbit.com> writes:
> 
> > On Sun, Aug 01, 2010 at 04:52:42PM -0700, Linus Torvalds wrote:
> >> On a slightly happier note: one thing I do hope we can merge in the
> >> upcoming merge window is Nick Piggin's cool VFS scalability series.
> >> I've been using it on my own machine, and gone through all the commits
> >> (not that I shouldn't go through some of them some more), and am
> >> personally really excited about it. It's seldom we see major
> >> performance improvements in core code that are quite that noticeable,
> >> and Nick's whole RCU pathname lookup in particular just tickles me
> >> pink.
> >
> > There hasn't been nearly enough review or testing of this patch
> > series yet.  Before a merge, it needs to be split up in smaller,
> > more digestable chunks for more comprehensive review, regression
> > testing and behavioural analysis.
> 
> We started some testing of the VFS series on larger systems and so
> far it looks all very good and the performance improvements are impressive
> (but of course new bottlenecks are being exposed then)
> 
> The only snag found so far was that an ACL enabled file system
> disables all the nice path walk improvements, so right now you
> need to remount with noacl. I'm hoping this can be fixed
> before a mainline release, otherwise I suspect it would disable
> the improvements for lots of people (common distributions default
> to acl on)

OK, vfs-scale-working branch now has commits to enable rcu-walk aware
d_revalidate, permission, and check_acl in the filesystems, and
implements a basic rcu-walk aware scheme for generic/posix acls and
implements that for tmpfs, ext2, btrfs. It just drops out of rcu-walk
if there is an ACL on a directory, or if it is not cached. I think
that's enough to be production ready now. Pushing rcu-walk awareness
down into acl checking code would not be hard.

I was under the impression that ACLs on directories are not that common,
so maybe this is as far as we need to go for now anyway.

It does need more commenting of the new methods and explaining how they
can and can't be used by filesystems. The tree is also getting messy
with incremental changes -- I'm avoiding rebasing it so people following
it can see response to reviews and issues that arise. Obviously it will
all get cleaned up and rebased properly onto a new branch before
anything is merged.

Re: Linux 2.6.35

[Andi Kleen]

On Tue, Aug 03, 2010 at 07:28:23PM +1000, Nick Piggin wrote:
> OK, vfs-scale-working branch now has commits to enable rcu-walk aware
> d_revalidate, permission, and check_acl in the filesystems, and
> implements a basic rcu-walk aware scheme for generic/posix acls and

Cool. I was just looking at that.

> I was under the impression that ACLs on directories are not that common,
> so maybe this is as far as we need to go for now anyway.

Yes it shouldn't be common normally. I think the common case for distros
is just a few ACLs in /dev. Of course you never know for 
specific end user workloads.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Linux 2.6.35

[Henrique de Moraes Holschuh]

On Tue, 03 Aug 2010, Nick Piggin wrote:
> I was under the impression that ACLs on directories are not that common,
> so maybe this is as far as we need to go for now anyway.

They are quite common on fileserver data areas, at least on the places where
I worked at.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Thomas Backlund]

Hi,
(please cc me as I'm not subscribed)

updating from make 3.81 to 3.82 gets me this:

[thomas@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
[thomas@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc
/mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed 
implicit and normal rules.  Stop.

The lines are:

182:
183: $(BOOT_TARGETS): vmlinux
184:         $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst 
%,$(boot)/%,$@)
185:

BOOT_TARGETS are defined on line 166 as:
BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% 
cuImage.% simpleImage.%


Now it's not a regression in the kernel as the same happends with the 
2.6.34 tree too.

(btw, the host I'm syncing the defconfig with is a x86_64 machine)


Now, I dont know if this is "intended breakage" by the make update, or 
if the Makefile needs to be updated....

Any ideas how to fix ?

--
Thomas

Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Sam Ravnborg]

On Mon, Aug 02, 2010 at 11:51:11AM +0300, Thomas Backlund wrote:
> Hi,
> (please cc me as I'm not subscribed)
>
> updating from make 3.81 to 3.82 gets me this:
>
> [thomas@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
> [thomas@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc
> /mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed  
> implicit and normal rules.  Stop.
>
> The lines are:
>
> 182:
> 183: $(BOOT_TARGETS): vmlinux
> 184:         $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst  
> %,$(boot)/%,$@)
> 185:
>
> BOOT_TARGETS are defined on line 166 as:
> BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.%  
> cuImage.% simpleImage.%
>
>
> Now it's not a regression in the kernel as the same happends with the  
> 2.6.34 tree too.
>
> (btw, the host I'm syncing the defconfig with is a x86_64 machine)
>
>
> Now, I dont know if this is "intended breakage" by the make update, or  
> if the Makefile needs to be updated....
>
> Any ideas how to fix ?

This is in the category "intended breakage".
We had a similar issue in the top-level Makefile which Paul (IIRC)
helped me to fix long time ago.

To fix popwerpc I suggest something along these lines.
[Note: I did not test it - please do so.

	Sam

[PATCH] powerpc: fix build with make 3.82

Thomas Backlund reported that the powerpc build broke with make 3.82.
It failed with the following message:

    arch/powerpc/Makefile:183: *** mixed implicit and normal rules.  Stop.

The fix is to avoid mixing non-wildcard and wildcard targets.

Reported-by: Thomas Backlund <tmb@mandriva.org>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 77cfe7a..ad88b21 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE)	+= arch/powerpc/oprofile/
 # Default to zImage, override when needed
 all: zImage
 
-BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
+# With make 3.82 we cannot mix normal and wildcard targets
+BOOT_TARGETS1 := zImage zImage.initrd uImaged
+BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
 
-PHONY += $(BOOT_TARGETS)
+PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
 
 boot := arch/$(ARCH)/boot
 
@@ -180,7 +182,9 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
 zImage: relocs_check
 endif
 
-$(BOOT_TARGETS): vmlinux
+$(BOOT_TARGETS1): vmlinux
+	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
+$(BOOT_TARGETS2): vmlinux
 	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
 
 bootwrapper_install %.dtb:

Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Thomas Backlund]

02.08.2010 21:28, Sam Ravnborg skrev:
> On Mon, Aug 02, 2010 at 11:51:11AM +0300, Thomas Backlund wrote:
>> Hi,
>> (please cc me as I'm not subscribed)
>>
>> updating from make 3.81 to 3.82 gets me this:
>>
>> [thomas@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
>> [thomas@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc
>> /mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed  
>> implicit and normal rules.  Stop.
>>
>> The lines are:
>>
>> 182:
>> 183: $(BOOT_TARGETS): vmlinux
>> 184:         $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst  
>> %,$(boot)/%,$@)
>> 185:
>>
>> BOOT_TARGETS are defined on line 166 as:
>> BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.%  
>> cuImage.% simpleImage.%
>>
>>
>> Now it's not a regression in the kernel as the same happends with the  
>> 2.6.34 tree too.
>>
>> (btw, the host I'm syncing the defconfig with is a x86_64 machine)
>>
>>
>> Now, I dont know if this is "intended breakage" by the make update, or  
>> if the Makefile needs to be updated....
>>
>> Any ideas how to fix ?
> 
> This is in the category "intended breakage".
> We had a similar issue in the top-level Makefile which Paul (IIRC)
> helped me to fix long time ago.
> 
> To fix popwerpc I suggest something along these lines.
> [Note: I did not test it - please do so.
> 
> 	Sam
> 
> [PATCH] powerpc: fix build with make 3.82
> 
> Thomas Backlund reported that the powerpc build broke with make 3.82.
> It failed with the following message:
> 
>     arch/powerpc/Makefile:183: *** mixed implicit and normal rules.  Stop.
> 
> The fix is to avoid mixing non-wildcard and wildcard targets.
> 
> Reported-by: Thomas Backlund <tmb@mandriva.org>
> Cc: Michal Marek <mmarek@suse.cz>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 77cfe7a..ad88b21 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE)	+= arch/powerpc/oprofile/
>  # Default to zImage, override when needed
>  all: zImage
>  
> -BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
> +# With make 3.82 we cannot mix normal and wildcard targets
> +BOOT_TARGETS1 := zImage zImage.initrd uImaged
> +BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
>  
> -PHONY += $(BOOT_TARGETS)
> +PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
>  
>  boot := arch/$(ARCH)/boot
>  
> @@ -180,7 +182,9 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
>  zImage: relocs_check
>  endif
>  
> -$(BOOT_TARGETS): vmlinux
> +$(BOOT_TARGETS1): vmlinux
> +	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> +$(BOOT_TARGETS2): vmlinux
>  	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>  
>  bootwrapper_install %.dtb:


Thanks, this seems to fix the first issue, but then I get the same erro on the following line 190:

190: bootwrapper_install %.dtb:
191:        $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)


--
Thomas

Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Sam Ravnborg]

> 
> Thanks, this seems to fix the first issue, but then I get the same erro on the following line 190:
> 
> 190: bootwrapper_install %.dtb:
> 191:        $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> 

Obviously - dunno how I missed that.
Updated patch below.

I will do a proper submission after you
confirm that powerpc build is working with make 3.82.

	Sam

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 77cfe7a..ace7a3e 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE)	+= arch/powerpc/oprofile/
 # Default to zImage, override when needed
 all: zImage
 
-BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
+# With make 3.82 we cannot mix normal and wildcard targets
+BOOT_TARGETS1 := zImage zImage.initrd uImaged
+BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
 
-PHONY += $(BOOT_TARGETS)
+PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
 
 boot := arch/$(ARCH)/boot
 
@@ -180,10 +182,16 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
 zImage: relocs_check
 endif
 
-$(BOOT_TARGETS): vmlinux
+$(BOOT_TARGETS1): vmlinux
+	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
+$(BOOT_TARGETS2): vmlinux
+	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
+
+
+bootwrapper_install
 	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
 
-bootwrapper_install %.dtb:
+%.dtb:
 	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
 
 define archhelp

Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Andreas Schwab]

Sam Ravnborg <sam@ravnborg.org> writes:

> +bootwrapper_install

Missing colon.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Thomas Backlund]

02.08.2010 23:51, Sam Ravnborg skrev:
>>
>> Thanks, this seems to fix the first issue, but then I get the same erro on the following line 190:
>>
>> 190: bootwrapper_install %.dtb:
>> 191:        $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>>
> 
> Obviously - dunno how I missed that.
> Updated patch below.
> 
> I will do a proper submission after you
> confirm that powerpc build is working with make 3.82.
> 

Yeah, that was an obvious fix, thanks!

One small typo fix below...
(a missing ':')

Otherwise it works here, so:

Tested-by: Thomas Backlund <tmb@mandriva.org>

> 	Sam
> 
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 77cfe7a..ace7a3e 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE)	+= arch/powerpc/oprofile/
>  # Default to zImage, override when needed
>  all: zImage
>  
> -BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
> +# With make 3.82 we cannot mix normal and wildcard targets
> +BOOT_TARGETS1 := zImage zImage.initrd uImaged
> +BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
>  
> -PHONY += $(BOOT_TARGETS)
> +PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
>  
>  boot := arch/$(ARCH)/boot
>  
> @@ -180,10 +182,16 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
>  zImage: relocs_check
>  endif
>  
> -$(BOOT_TARGETS): vmlinux
> +$(BOOT_TARGETS1): vmlinux
> +	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> +$(BOOT_TARGETS2): vmlinux
> +	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> +
> +
> +bootwrapper_install

bootwrapper_install:

>  	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>  
> -bootwrapper_install %.dtb:
> +%.dtb:
>  	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>  
>  define archhelp
> .
> 

--
Thomas

Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Sam Ravnborg]

On Tue, Aug 03, 2010 at 12:03:35AM +0300, Thomas Backlund wrote:
> 02.08.2010 23:51, Sam Ravnborg skrev:
> >>
> >> Thanks, this seems to fix the first issue, but then I get the same erro on the following line 190:
> >>
> >> 190: bootwrapper_install %.dtb:
> >> 191:        $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> >>
> > 
> > Obviously - dunno how I missed that.
> > Updated patch below.
> > 
> > I will do a proper submission after you
> > confirm that powerpc build is working with make 3.82.
> > 
> 
> Yeah, that was an obvious fix, thanks!
> 
> One small typo fix below...
> (a missing ':')
> 
> Otherwise it works here, so:
> 
> Tested-by: Thomas Backlund <tmb@mandriva.org>

Thanks.
I have sent a proper patch to Ben/Paul (powerpc maintainers).

	Sam

Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Paul Smith]

On Mon, 2010-08-02 at 11:51 +0300, Thomas Backlund wrote:
> BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage%
> treeImage.% cuImage.% simpleImage.%
> 
> Now, I dont know if this is "intended breakage" by the make update, or 
> if the Makefile needs to be updated....

The change is intentional.  Note, though, that this syntax was always
dodgy, even in previous versions of GNU make.

If you wrote it exactly as you did, where all the explicit targets come
first and all the implicit targets come second, then it seems to have
been interpreted correctly.

However, if you did it any other way (for example, put some explicit
targets after the first implicit target) then make would silently throw
away all the targets starting with the first implicit target.

Since the syntax used here wasn't ever described in the documentation,
rather than reworking it as a new feature I decided to follow the docs
and disallow it, and be verbose about the error.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist