Linux v2.6.29-rc5

Linux v2.6.29-rc5

[Linus Torvalds]

It's a (faked) magical moment to release a kernel, so there it is. 

The dirstat shows it all:

  88.6% drivers/net/
   4.9% drivers/staging/at76_usb/

ie practically all of the changes come from some driver updates, the bnx2 
firmware update, and one of the staging drivers. And even there, the bulk 
of the changes to the at76_usb driver was actually a revert.

All the rest is pretty much a collection of trivial small fixes. Yes, 
there's a Intel SVDO update that shows up in diffstat, but the rest 
really is pretty tiny.

Which is just how I like it.

So go out and test the heck out of it, because I'm going to spend the 
three-day weekend drunk at the beach. Because somebody has to do it.

		Linus

---
Adrian-Ken Rueegsegger (1):
      crypto: shash - Fix module refcount

Alan Stern (2):
      USB: usb-storage: remove WARN from last-sector hacks
      USB: usb-storage: add Pentax to the bad-vendor list

Alex Chiang (1):
      x86: fix grammar in user-visible BIOS warning

Alex Williamson (1):
      tun: Fix unicast filter overflow

Alok Kataria (1):
      x86, vmi: put a missing paravirt_release_pmd in pgd_dtor

Ananth N Mavinakayanahalli (1):
      powerpc: Don't emulate mr. instructions

Andres Salomon (2):
      gxfb: properly alloc cmap and plug cmap leak
      gx1fb: properly alloc cmap and plug cmap leak

Andrew Morton (2):
      net: don't use in_atomic() in gfp_any()
      Documentation/connector/cn_test.c: don't use gfp_any()

Anton Vorontsov (8):
      powerpc/83xx: Fix missing #{address,size}-cells in mpc8313erdb.dts
      powerpc/83xx: Fix TSEC0 workability on MPC8313E-RDB boards
      USB: fsl_qe_udc: Fix oops on QE UDC probe failure
      USB: fsl_qe_udc: Fix recursive locking bug in ch9getstatus()
      USB: fsl_qe_udc: Fix QE USB controller initialization
      USB: fsl_qe_udc: Fix disconnects reporting during bus reset
      USB: fsl_qe_udc: Fix muram corruption by disabled endpoints
      USB: fsl_qe_udc: Fix stalled TX requests bug

Arnd Bergmann (1):
      sound: Remove OSSlib stuff from linux/soundcard.h

Arve Hjønnevåg (1):
      Staging: android: ram_console: Disable ECC when early init is enabled and validate buffer size

Balaji Rao (1):
      pcf50633_charger: Fix typo

Benjamin Herrenschmidt (1):
      powerpc/pci: mmap anonymous memory when legacy_mem doesn't exist

Bob Copeland (1):
      ath5k: fix bf->skb==NULL panic in ath5k_tasklet_rx

Borislav Petkov (1):
      x86/Kconfig.cpu: make Kconfig help readable in the console

Carsten Otte (1):
      ext2/xip: refuse to change xip flag during remount with busy inodes

Chris Mason (1):
      Btrfs: don't use spin_is_contended

Chris Wilson (2):
      drm/i915: Unref the object after failing to set tiling mode.
      drm/i915: Unlock mutex on i915_gem_fault() error path

Chuck Ebbert (1):
      pkt_sched: type should be __u32 in header

Clemens Ladisch (1):
      i8327: fix outb() parameter order

Clément Lecigne (1):
      net: 4 bytes kernel memory disclosure in SO_BSDCOMPAT gsopt try #2

Cornelia Huck (1):
      [S390] dasd: bus_id -> dev_name() conversion.

Daisuke Nishimura (1):
      migration: migrate_vmas should check "vma"

Dan Carpenter (1):
      USB: ftdi_sio: unlock_kernel() on error in set_serial_info()

Dave Airlie (2):
      i915: fix unneeded locking in i915 LVDS get modes code.
      drm/radeon: fix ioremap conflict with AGP mappings

Dave Young (1):
      USB: usb-serial: fix the aircable_init failure path

David Howells (2):
      RxRPC: Fix a potential NULL dereference
      FRV: in_interrupt() requires #inclusion of linux/hardirq.h not asm/hardirq.h now

David S. Miller (7):
      sparc64: Call dump_stack() in die_nmi().
      sparc64: Don't hook up pcr_ops on spitfire chips.
      ipv6: Disallow rediculious flowlabel option sizes.
      net_dma: call dmaengine_get only if NET_DMA enabled
      sunhme: Don't match PCI devices in SBUS probe.
      sparc64: Kill .fixup section bloat.
      sparc64: Fix probe_kernel_{read,write}().

Dhananjay Phadke (2):
      netxen: fix msi-x interrupt handling
      netxen: remove pcie workaround

Dirk De Schepper (1):
      USB: option: New mobile broadband modems to be supported

Eero Nurkkala (1):
      ASoC: TLV320AIC3X: Fix kcontrol's private value use in put callback

Eric Anholt (5):
      drm/i915: Suppress GEM teardown on X Server exit in KMS mode.
      drm/i915: Skip SDVO/HDMI init when the chipset tells us it's not present.
      drm/i915: Set up an MTRR covering the GTT at driver load.
      drm/i915: Return error from i915_gem_object_get_fence_reg() when failing.
      drm/i915: Quiet the message on get/setparam ioctl with an unknown value.

Eric Leblond (2):
      netfilter: fix tuple inversion for Node information request
      netfilter: nf_conntrack_ipv6: don't track ICMPv6 negotiation message

Eric Miao (3):
      [ARM] pxa: fix missing of __REG() definition for ac97 registers access
      [ARM] pxa: make more SSCR0 bit definitions visible on multiple processors
      [ARM] pxa: stop and disable IRQ for each DMA channels at startup

Eric Van Hensbergen (1):
      9p: fix endian issues [attempt 3]

Federico Cuello (1):
      writeback: fix break condition

Gautam Kachroo (1):
      neigh: some entries can be skipped during dumping

Greg Kroah-Hartman (3):
      Revert USB: option: add Pantech cards
      Revert Staging: at76_usb: update drivers/staging/at76_usb w/ mac80211 port
      Staging: android: fix up units in timed_gpio

Heiko Carstens (1):
      syscall define: fix uml compile bug

Herbert Xu (5):
      crypto: api - Fix algorithm test race that broke aead initialisation
      crypto: api - Fix zeroing on free
      crypto: shash - Fix tfm destruction
      crypto: scatterwalk - Avoid flush_dcache_page on slab pages
      bridge: Fix LRO crash with tun

Herton Ronaldo Krzesinski (1):
      ALSA: hda - Change HP dv7 (103c:30f4) quirk from hp-m4 to hp-dv5 model

Hin-Tak Leung (2):
      zd1211rw: adding 0ace:0xa211 as a ZD1211 device
      zd1211rw: treat MAXIM_NEW_RF(0x08) as UW2453_RF(0x09) for TP-Link WN322/422G

Hugh Dickins (2):
      mm: fix error case in mlock downgrade reversion
      profiling: fix broken profiling regression

Ian Dall (1):
      w1: w1 temp calculation overflow fix

Ilkka Virta (1):
      sungem: Soft lockup in sungem on Netra AC200 when switching interface up

Inaky Perez-Gonzalez (1):
      wimax: fix oops in wimax_dev_get_by_genl_info() when looking up non-wimax iface

Ingo Molnar (2):
      timers: split process wide cpu clocks/timers, remove spurious warning
      drm/i915: select framebuffer support automatically

Ivan Kuten (1):
      USB: Correct Makefile to make isp1760 buildable

Ivan Vecera (1):
      r8169: Don't update statistics counters when interface is down

J. Bruce Fields (1):
      lockd: fix regression in lockd's handling of blocked locks

James Treacy (1):
      USB: cdc-acm.c: remove duplicate lines for MTK gps support

Jamie Lentin (1):
      Staging: at76_usb: Add support for OQO Model 01+

Jan Kara (2):
      jbd: fix return value of journal_start_commit()
      ext3: revert "ext3: wait on all pending commits in ext3_sync_fs"

Jarek Poplawski (1):
      gianfar: Fix boot hangs while bringing up gianfar ethernet

Jarkko Nikula (1):
      ASoC: WM8990: Fix kcontrol's private value use in put callback

Jason Andryuk (1):
      Staging: at76_usb: fix bugs introduced by "Staging: at76_usb: cleanup dma on stack issues"

Jeremy Fitzhardinge (2):
      x86: don't apply __supported_pte_mask to non-present ptes
      mm: rearrange exit_mmap() to unlock before arch_exit_mmap

Jesper Dangaard Brouer (1):
      udp: Fix potential wrong ip_hdr(skb) pointers

Jesse Barnes (4):
      drm/i915: add fence register management to execbuf
      drm/i915: sync SDVO code with stable userland modesetting driver
      drm/i915: capture last_vblank count at IRQ uninstall time too
      drm/i915: add get_vblank_counter function for GM45

Jiri Slaby (1):
      parport: parport_serial, don't bind netmos ibm 0299

Johannes Berg (1):
      mac80211: restrict to AP in outgoing interface heuristic

Julia Lawall (3):
      arch/powerpc: Eliminate double sizeof
      drivers/atm: introduce missing kfree
      drivers/isdn: introduce missing kfree

KAMEZAWA Hiroyuki (1):
      memcg: use __GFP_NOWARN in page cgroup allocation

KOSAKI Motohiro (1):
      cgroups: add Li Zefan as a maintainer

Kirill A. Shutemov (1):
      mm: Export symbol ksize()

Kumar Gala (2):
      powerpc/fsl-booke: Fix mapping functions to use phys_addr_t
      powerpc/mm: Fix _PAGE_COHERENT support on classic ppc32 HW

Kyle McMartin (3):
      x86, 64-bit: print DMI info in the oops trace
      x86: disable intel_iommu support by default
      x86: spinlocks: define dummy __raw_spin_is_contended

Li Zefan (1):
      cgroups: fix lockdep subclasses overflow

Linus Torvalds (2):
      i915: Fix more size_t format string warnings
      Linux 2.6.29-rc5

Lopez Cruz, Misael (1):
      ASoC: Update SDP3430 machine driver for snd_soc_card

Mackenzie Morgan (1):
      ALSA: hda - Add quirk for Asus z37e (1043:8284)

Marcel Selhorst (1):
      tpm: correct email address for tpm_infineon-driver

Marco La Porta (1):
      lxfb: properly alloc cmap in all cases and don't leak the memory

Mark Brown (1):
      ASoC: Only register AC97 bus if it's not done already

Mark Langsdorf (1):
      [CPUFREQ] powernow-k8: Get transition latency from ACPI _PSS table

Martin Schwidefsky (2):
      [S390] vdso: fix per cpu vdso pointer in lowcore
      [S390] Update default configuration.

Meelis Roos (2):
      fore200: fix oops on failed firmware load
      sunhme: Fix Quattro HME irq registration on proble failures

Mel Gorman (2):
      Do not account for the address space used by hugetlbfs using VM_ACCOUNT
      Do not account for hugetlbfs quota at mmap() time if mapping [SHM|MAP]_NORESERVE

Michael Chan (4):
      bnx2: Update 5706/5708 firmware.
      bnx2: Update 5709 firmware.
      bnx2: Fix jumbo frames error handling.
      bnx2: Update version to 1.9.2 and copyright.

Michael Neuling (3):
      powerpc/83xx: Build breakage for CONFIG_PM but no CONFIG_SUSPEND
      powerpc/cell: Add missing #include for oprofile
      powerpc: Add missing sparsemem.h include

Mike Rapoport (1):
      [ARM] pxa: fix NAND and MMC clock initialization for pxa3xx

MinChan Kim (1):
      mm: fix mlocked page counter mismatch

Nick Holloway (1):
      USB: Storage: Update unusual_devs entry for Datafab KECF-USB

Nick Piggin (1):
      Fix page writeback thinko, causing Berkeley DB slowdown

Noriaki TAKAMIYA (1):
      IPv6: fix to set device name when new IPv6 over IPv6 tunnel device is created.

Oleg Nesterov (1):
      ptrace, x86: fix the usage of ptrace_fork()

Oliver Neukum (1):
      USB: two more usb ids for ti_usb_3410_5052

Ondrej Zary (1):
      3c509: Fix resume from hibernation for PnP mode.

Pablo Neira Ayuso (2):
      netfilter: ctnetlink: allow changing NAT sequence adjustment in creation
      netfilter: ctnetlink: fix echo if not subscribed to any multicast group

Pallipadi, Venkatesh (1):
      x86: add clflush before monitor for Intel 7400 series

Paul Clements (1):
      nbd: fix I/O hang on disconnected nbds

Paul Collins (1):
      drm/i915: skip LVDS initialization on Apple Mac Mini

Paulius Zaleckas (1):
      mdio-gpio: Add mdc pin direction initialization

Pavel Emelyanov (2):
      x86: fix hpet timer reinit for x86_64
      x86: clean up hpet timer reinit

Peter Zijlstra (5):
      signal: re-add dead task accumulation stats.
      timers: split process wide cpu clocks/timers
      timers: split process wide cpu clocks/timers, fix
      timers: fix TIMER_ABSTIME for process wide cpu timers
      sched: revert recent sync wakeup changes

Qu Haoran (1):
      netfilter: xt_sctp: sctp chunk mapping doesn't work

Randy Dunlap (2):
      kernel-doc: preferred ending marker and examples
      kernel-doc: fix syscall wrapper processing

Reinette Chatre (1):
      iwlwifi: fix suspend/resume and its usage of pci saved state

Risto Suominen (1):
      de2104x: force correct order when writing to rx ring

Robert Jarzmik (1):
      rtc: update maintainership of pxa rtc driver

Roel Kluin (6):
      [ARM] AACI: timeout will reach -1
      rtc: t reaches -1, tested 0
      TG3: limit reaches -1
      sun3: print when lance_open() fails
      IRDA: cnt is off by 1
      3c505: do not set pcb->data.raw beyond its size

Ron Mercer (7):
      qlge: bugfix: Use netif_receive_skb() and vlan_hwaccel_receive_skb().
      qlge: bugfix: Fix fatal error recovery hang.
      qlge: bugfix: Add missing put_page() call.
      qlge: bugfix: Add missing dev_kfree_skb_any() call.
      qlge: bugfix: Fix TSO breakage.
      qlge: bugfix: Fix RX scaling values.
      qlge: bugfix: Add missing rx buf clean index on early exit.

Rémi Denis-Courmont (2):
      Phonet: fix double free in GPRS outbound packet error path
      Phonet: do not compute unused value

Sachin P. Sant (1):
      Staging: panel: fix lcd panel driver build failure

Sachin Sant (1):
      [S390] Fix init irq proc build break.

Serge E. Hallyn (1):
      User namespaces: Only put the userns when we unhash the uid

Stefan Richter (1):
      hugetlbfs: fix build failure with !CONFIG_HUGETLBFS

Stefan Weinhuber (1):
      [S390] dasd: fix race in dasd timer handling

Stephane Clerambault (1):
      USB: ftdi_sio: add support for the NDI Polaris system

Steven Rostedt (3):
      powerpc/ftrace: Fix math to calculate offset in TOC
      tracing, x86: fix fixup section to return to original code
      tracing, x86: fix constraint for parent variable

Suresh Siddha (1):
      sched: fix nohz load balancer on cpu offline

Sven Wegener (1):
      mm: fix dirty_bytes/dirty_background_bytes sysctls on 64bit arches

Takashi Iwai (4):
      ALSA: mtpav - Fix initial value for input hwport
      ALSA: hda - Register (new) devices at reconfig
      ALSA: hda - Add missing terminator in slave dig-out array
      ALSA: hda - Add snd_hda_multi_out_dig_cleanup()

Tejun Heo (3):
      x86: include correct %gs in a.out core dump
      x86: math_emu info cleanup
      x86: fix math_emu register frame access

Tobias Klauser (1):
      [ARM] Storage class should be before const qualifier

Uwe Kleine-Koenig (1):
      video/framebuffer: move the probe func into .devinit.text in Blackfin LCD driver

Venkatesh Pallipadi (1):
      [CPUFREQ] Make ignore_nice_load setting of ondemand work as expected.

Wu Fengguang (4):
      ALSA: hda - allow multi-channel HDMI audio playback when ELD is not present
      ALSA: hda - enable HDMI audio pin out at module loading time
      ALSA: hda - compute checksum in HDMI audio infoframe
      ALSA: hda - add id for Intel IbexPeak integrated HDMI codec

Yang Hongyang (1):
      netxen: fix compile waring "label ‘set_32_bit_mask’ defined but not used" on IA64 platform

Yinghai Lu (1):
      x86: find nr_irqs_gsi with mp_ioapic_routing

paulfax (1):
      powerpc/cpm2: Fix set interrupt type

Bonding tied to IPV6 in 29-rc5

[J.A. Magallón]

Hi all...

Don't know if this is specific for -rc5, I have jumped from 28.4 to 29-rc5.
In this latest kernel, I can not install 'bonding' module if 'ipv6' is
disabled to load via modprobe.conf:

install ipv6 /bin/true

Trying bonding gives this dmesg:

bonding: Unknown symbol ndisc_build_skb
bonding: Unknown symbol in6_dev_finish_destroy
bonding: Unknown symbol ndisc_send_skb
bonding: Unknown symbol unregister_inet6addr_notifier
bonding: Unknown symbol register_inet6addr_notifier

Commenting the line in modprobe.conf makes things smooth again.
We can not disable ipv6 anymore ?

TIA

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2009.1 (Cooker) for x86_64
Linux 2.6.28.2-desktop-1mnb (gcc 4.3.2 (GCC) #1 Wed Jan

2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Andrey Borzenkov]

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

Forward to bonding and netdev

On 17 of February 2009 11:52:32 J.A. Magallón wrote:
> Hi all...
>
> Don't know if this is specific for -rc5, I have jumped from 28.4 to
> 29-rc5. In this latest kernel, I can not install 'bonding' module if
> 'ipv6' is disabled to load via modprobe.conf:
>
> install ipv6 /bin/true
>
> Trying bonding gives this dmesg:
>
> bonding: Unknown symbol ndisc_build_skb
> bonding: Unknown symbol in6_dev_finish_destroy
> bonding: Unknown symbol ndisc_send_skb
> bonding: Unknown symbol unregister_inet6addr_notifier
> bonding: Unknown symbol register_inet6addr_notifier
>
> Commenting the line in modprobe.conf makes things smooth again.
> We can not disable ipv6 anymore ?
>

If IPv6 is disable in kernel config bonding loads. But I think it is 
regression, it should be possible to disable IPv6 if not required.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Andrey Borzenkov]

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

On 17 of February 2009 20:01:38 Andrey Borzenkov wrote:
> Forward to bonding and netdev
>
> On 17 of February 2009 11:52:32 J.A. Magallón wrote:
> > Hi all...
> >
> > Don't know if this is specific for -rc5, I have jumped from 28.4 to
> > 29-rc5. In this latest kernel, I can not install 'bonding' module
> > if 'ipv6' is disabled to load via modprobe.conf:
> >
> > install ipv6 /bin/true
> >
> > Trying bonding gives this dmesg:
> >
> > bonding: Unknown symbol ndisc_build_skb
> > bonding: Unknown symbol in6_dev_finish_destroy
> > bonding: Unknown symbol ndisc_send_skb
> > bonding: Unknown symbol unregister_inet6addr_notifier
> > bonding: Unknown symbol register_inet6addr_notifier
> >
> > Commenting the line in modprobe.conf makes things smooth again.
> > We can not disable ipv6 anymore ?
>
> If IPv6 is disable in kernel config bonding loads. But I think it is
> regression, it should be possible to disable IPv6 if not required.

This hard dependency was apparently introduced by this commit:

commit 305d552accae6afb859c493ebc7d98ca3371dae2
Author: Brian Haley <brian.haley@hp.com>
Date:   Tue Nov 4 17:51:14 2008 -0800

    bonding: send IPv6 neighbor advertisement on failover


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Jay Vosburgh]

Andrey Borzenkov <arvidjaar@mail.ru> wrote:

>> If IPv6 is disable in kernel config bonding loads. But I think it is
>> regression, it should be possible to disable IPv6 if not required.
>
>This hard dependency was apparently introduced by this commit:
>
>commit 305d552accae6afb859c493ebc7d98ca3371dae2
>Author: Brian Haley <brian.haley@hp.com>
>Date:   Tue Nov 4 17:51:14 2008 -0800
>
>    bonding: send IPv6 neighbor advertisement on failover

	I'm not really sure how to work around this.  If bonding is
compiled with CONFIG_IPV6, then the IPv6 support is compiled in, and
bonding will need the ipv6 module loaded to resolve its symbols.

	The simple answer (don't turn on CONFIG_IPV6) isn't really
useful for the common case of distro kernels, which will generally have
CONFIG_IPV6 enabled.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Brian Haley]

Andrey Borzenkov wrote:
> On 17 of February 2009 20:01:38 Andrey Borzenkov wrote:
>> Forward to bonding and netdev
>>
>> On 17 of February 2009 11:52:32 J.A. Magallón wrote:
>>> Hi all...
>>>
>>> Don't know if this is specific for -rc5, I have jumped from 28.4 to
>>> 29-rc5. In this latest kernel, I can not install 'bonding' module
>>> if 'ipv6' is disabled to load via modprobe.conf:
>>>
>>> install ipv6 /bin/true
>>>
>>> Trying bonding gives this dmesg:
>>>
>>> bonding: Unknown symbol ndisc_build_skb
>>> bonding: Unknown symbol in6_dev_finish_destroy
>>> bonding: Unknown symbol ndisc_send_skb
>>> bonding: Unknown symbol unregister_inet6addr_notifier
>>> bonding: Unknown symbol register_inet6addr_notifier
>>>
>>> Commenting the line in modprobe.conf makes things smooth again.
>>> We can not disable ipv6 anymore ?
>> If IPv6 is disable in kernel config bonding loads. But I think it is
>> regression, it should be possible to disable IPv6 if not required.
> 
> This hard dependency was apparently introduced by this commit:
> 
> commit 305d552accae6afb859c493ebc7d98ca3371dae2
> Author: Brian Haley <brian.haley@hp.com>
> Date:   Tue Nov 4 17:51:14 2008 -0800
> 
>     bonding: send IPv6 neighbor advertisement on failover

I initially had bonding IPv6 support as a Kconfig option, but it was 
decided it would be cleaner if it just got built-in whenever CONFIG_IPV6 
was set like SCTP, with the assumption you might want it.

Is it a common configuration to not allow a module to load like you're 
doing in modprobe.conf?  I don't know how hard it would be to rip this 
out into it's own bonding_ipv6.ko module, simply turning-off CONFIG_IPV6 
seems better.

-Brian

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Thomas Backlund]

Brian Haley skrev:
> Andrey Borzenkov wrote:
>> On 17 of February 2009 20:01:38 Andrey Borzenkov wrote:
>>> Forward to bonding and netdev
>>>
>>> On 17 of February 2009 11:52:32 J.A. Magallón wrote:
>>>> Hi all...
>>>>
>>>> Don't know if this is specific for -rc5, I have jumped from 28.4 to
>>>> 29-rc5. In this latest kernel, I can not install 'bonding' module
>>>> if 'ipv6' is disabled to load via modprobe.conf:
>>>>
>>>> install ipv6 /bin/true
>>>>
>>>> Trying bonding gives this dmesg:
>>>>
>>>> bonding: Unknown symbol ndisc_build_skb
>>>> bonding: Unknown symbol in6_dev_finish_destroy
>>>> bonding: Unknown symbol ndisc_send_skb
>>>> bonding: Unknown symbol unregister_inet6addr_notifier
>>>> bonding: Unknown symbol register_inet6addr_notifier
>>>>
>>>> Commenting the line in modprobe.conf makes things smooth again.
>>>> We can not disable ipv6 anymore ?
>>> If IPv6 is disable in kernel config bonding loads. But I think it is
>>> regression, it should be possible to disable IPv6 if not required.
>>
>> This hard dependency was apparently introduced by this commit:
>>
>> commit 305d552accae6afb859c493ebc7d98ca3371dae2
>> Author: Brian Haley <brian.haley@hp.com>
>> Date:   Tue Nov 4 17:51:14 2008 -0800
>>
>>     bonding: send IPv6 neighbor advertisement on failover
> 
> I initially had bonding IPv6 support as a Kconfig option, but it was 
> decided it would be cleaner if it just got built-in whenever CONFIG_IPV6 
> was set like SCTP, with the assumption you might want it.
> 
> Is it a common configuration to not allow a module to load like you're 
> doing in modprobe.conf?  I don't know how hard it would be to rip this 

Yep.

> out into it's own bonding_ipv6.ko module, simply turning-off CONFIG_IPV6 
> seems better.

That's not an option for distro kernels ...

--
Thomas

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Jay Vosburgh]

Brian Haley <brian.haley@hp.com> wrote:

>Andrey Borzenkov wrote:
[...]
>> This hard dependency was apparently introduced by this commit:
>> 
>> commit 305d552accae6afb859c493ebc7d98ca3371dae2
>> Author: Brian Haley <brian.haley@hp.com>
>> Date:   Tue Nov 4 17:51:14 2008 -0800
>> 
>>     bonding: send IPv6 neighbor advertisement on failover
>
>I initially had bonding IPv6 support as a Kconfig option, but it was 
>decided it would be cleaner if it just got built-in whenever CONFIG_IPV6 
>was set like SCTP, with the assumption you might want it.
>
>Is it a common configuration to not allow a module to load like you're 
>doing in modprobe.conf?  I don't know how hard it would be to rip this 
>out into it's own bonding_ipv6.ko module, simply turning-off CONFIG_IPV6 
>seems better.

	I'm not sure either of those really helps.  Distro kernels are
built with CONFIG_IPV6 (and would have the CONFIG_BONDING_IPV6_DINGUS
enabled as well), so the common case users would have it enabled, too.

	Putting the ipv6 bits into a different module might not help,
either, because the "core" bonding code would still have the call to the
ipv6 functions.  Unless there's some magic way to somehow know at
runtime whether or not the ipv6 module is loaded, and only try to
resolve those symbols if ipv6 is loaded.  That seems complicated.

	To answer your question, I have come across this (aliasing ipv6
to nothing in modprobe.conf to disable IPv6) from time to time, but
didn't think of it when the NA code was added to bonding.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Brian Haley]

Jay Vosburgh wrote:
> Brian Haley <brian.haley@hp.com> wrote:
> 
>> Andrey Borzenkov wrote:
> [...]
>>> This hard dependency was apparently introduced by this commit:
>>>
>>> commit 305d552accae6afb859c493ebc7d98ca3371dae2
>>> Author: Brian Haley <brian.haley@hp.com>
>>> Date:   Tue Nov 4 17:51:14 2008 -0800
>>>
>>>     bonding: send IPv6 neighbor advertisement on failover
>> I initially had bonding IPv6 support as a Kconfig option, but it was 
>> decided it would be cleaner if it just got built-in whenever CONFIG_IPV6 
>> was set like SCTP, with the assumption you might want it.
>>
>> Is it a common configuration to not allow a module to load like you're 
>> doing in modprobe.conf?  I don't know how hard it would be to rip this 
>> out into it's own bonding_ipv6.ko module, simply turning-off CONFIG_IPV6 
>> seems better.
> 
> 	I'm not sure either of those really helps.  Distro kernels are
> built with CONFIG_IPV6 (and would have the CONFIG_BONDING_IPV6_DINGUS
> enabled as well), so the common case users would have it enabled, too.

I think that was one of the reasons too.

> 	Putting the ipv6 bits into a different module might not help,
> either, because the "core" bonding code would still have the call to the
> ipv6 functions.  Unless there's some magic way to somehow know at
> runtime whether or not the ipv6 module is loaded, and only try to
> resolve those symbols if ipv6 is loaded.  That seems complicated.

This separate bonding_ipv6 module would have to register itself with the 
"core" one with a new proto_ops of some sort.  Calls are made for the 
appropriate method, for example bond_ops->send_gratuitous(bond).  We'd 
change the IPv4 code too.  It's just a theory, does make things more 
complicated.

> 	To answer your question, I have come across this (aliasing ipv6
> to nothing in modprobe.conf to disable IPv6) from time to time, but
> didn't think of it when the NA code was added to bonding.

So I guess I'll start hacking the above, unless someone has a better 
suggestion.

-Brian

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[J.A. Magallón]

On Tue, 17 Feb 2009 16:49:16 -0500, Brian Haley <brian.haley@hp.com> wrote:

> Jay Vosburgh wrote:
> > Brian Haley <brian.haley@hp.com> wrote:
> > 
> >> Andrey Borzenkov wrote:
> > [...]
> >>> This hard dependency was apparently introduced by this commit:
> >>>
> >>> commit 305d552accae6afb859c493ebc7d98ca3371dae2
> >>> Author: Brian Haley <brian.haley@hp.com>
> >>> Date:   Tue Nov 4 17:51:14 2008 -0800
> >>>
> >>>     bonding: send IPv6 neighbor advertisement on failover
> >> I initially had bonding IPv6 support as a Kconfig option, but it was 
> >> decided it would be cleaner if it just got built-in whenever CONFIG_IPV6 
> >> was set like SCTP, with the assumption you might want it.
> >>
> >> Is it a common configuration to not allow a module to load like you're 
> >> doing in modprobe.conf?  I don't know how hard it would be to rip this 
> >> out into it's own bonding_ipv6.ko module, simply turning-off CONFIG_IPV6 
> >> seems better.
> > 
> > 	I'm not sure either of those really helps.  Distro kernels are
> > built with CONFIG_IPV6 (and would have the CONFIG_BONDING_IPV6_DINGUS
> > enabled as well), so the common case users would have it enabled, too.
> 
> I think that was one of the reasons too.
> 
> > 	Putting the ipv6 bits into a different module might not help,
> > either, because the "core" bonding code would still have the call to the
> > ipv6 functions.  Unless there's some magic way to somehow know at
> > runtime whether or not the ipv6 module is loaded, and only try to
> > resolve those symbols if ipv6 is loaded.  That seems complicated.
> 
> This separate bonding_ipv6 module would have to register itself with the 
> "core" one with a new proto_ops of some sort.  Calls are made for the 
> appropriate method, for example bond_ops->send_gratuitous(bond).  We'd 
> change the IPv4 code too.  It's just a theory, does make things more 
> complicated.
> 
> > 	To answer your question, I have come across this (aliasing ipv6
> > to nothing in modprobe.conf to disable IPv6) from time to time, but
> > didn't think of it when the NA code was added to bonding.
> 
> So I guess I'll start hacking the above, unless someone has a better 
> suggestion.

Perhaps the right way to start would be to think is if blocking the load
of ipv6 is the right way to disable IPV6.

Just as an example I realized recently (and I know it's not the same) if
I don't have ext4 loaded I can't format a disk on ext4. But disks still
work...

IPV6 looks like a special part of the kernel to disable _at runtime_.

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2009.1 (Cooker) for x86_64
Linux 2.6.28.2-desktop-1mnb (gcc 4.3.2 (GCC) #1 Wed Jan

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Jay Vosburgh]

Brian Haley <brian.haley@hp.com> wrote:

>Jay Vosburgh wrote:
[...]
>> 	Putting the ipv6 bits into a different module might not help,
>> either, because the "core" bonding code would still have the call to the
>> ipv6 functions.  Unless there's some magic way to somehow know at
>> runtime whether or not the ipv6 module is loaded, and only try to
>> resolve those symbols if ipv6 is loaded.  That seems complicated.
>
>This separate bonding_ipv6 module would have to register itself with the
>"core" one with a new proto_ops of some sort.  Calls are made for the
>appropriate method, for example bond_ops->send_gratuitous(bond).  We'd
>change the IPv4 code too.  It's just a theory, does make things more
>complicated.

	I don't see any reason to change the IPv4 bits; there won't ever
be a case of ipv4 not being loaded, and this would just add the
complexity of a registration gizmo with no real benefit.  A "bonding
ipv6 ops" would be strictly a hack to deal with ipv6 module dependencies
for cases when the kernel is built with CONFIG_IPV6 but the ipv6 module
itself is prevented from loading.

	A registration gizmo doesn't need to be especially complicated;
there's only three functions in bond_ipv6.c that are called from the
bonding core: bond_send_unsolicited_na, and the ipv6 notifier register /
unregister.  The bonding_ipv6 module can simply be bond_ipv6.c, which
calls some exported "hey, bond_send_unsol_na is here" thing in the
bonding core during init and another "hey, send_unsol_na is gone" during
unload.  The bonding_ipv6 module can do its own notifier registration
handing.

>> 	To answer your question, I have come across this (aliasing ipv6
>> to nothing in modprobe.conf to disable IPv6) from time to time, but
>> didn't think of it when the NA code was added to bonding.
>
>So I guess I'll start hacking the above, unless someone has a better
>suggestion.

	Well, I think this is pretty heinous, but I don't have a better
idea at the moment.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[David Miller]

From: Andrey Borzenkov <arvidjaar@mail.ru>
Date: Tue, 17 Feb 2009 20:01:38 +0300

> Forward to bonding and netdev
 ...
> If IPv6 is disable in kernel config bonding loads. But I think it is 
> regression, it should be possible to disable IPv6 if not required.

Don't configure ipv6 into your kernel, really.

There is no other way to handle this.  If we want to support
IPV6 layer things in the bonding driver, it is going to
call helper functions in the ipv6 module and therefore must
be able to load it and use functions in it.

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Nicolas de Pesloüan]

Jay Vosburgh wrote:
> 	I'm not sure either of those really helps.  Distro kernels are
> built with CONFIG_IPV6 (and would have the CONFIG_BONDING_IPV6_DINGUS
> enabled as well), so the common case users would have it enabled, too.
> 
> 	Putting the ipv6 bits into a different module might not help,
> either, because the "core" bonding code would still have the call to the
> ipv6 functions.  Unless there's some magic way to somehow know at
> runtime whether or not the ipv6 module is loaded, and only try to
> resolve those symbols if ipv6 is loaded.  That seems complicated.

What about aliasing ipv6 to a dummy module "dummy-ipv6-for-bonding" that 
only provide the required symbols and do (close to) nothing ?

Just my two cents.

     Nicolas.

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[David Miller]

From: Jay Vosburgh <fubar@us.ibm.com>
Date: Tue, 17 Feb 2009 12:08:03 -0800

> 	The simple answer (don't turn on CONFIG_IPV6) isn't really
> useful for the common case of distro kernels, which will generally have
> CONFIG_IPV6 enabled.

This whole "disable ipv6 module load in /etc/modules.conf" was
bound to eventually cause problems like this.

There are so many chicken-and-egg issues wrt. this it isn't
even funny, for example:

1) If we provide a sysctl which is a bitmask of protocols
   to disallow registering, we have the same problem we have
   now since ipv6 won't be able to load when the sock_register()
   fails.

2) If we add some ipv6 sysctl that says "don't do ipv6" so the
   module can load yet not automatically add link local ipv6
   addresses to interfaces and solicit for routers on the network,
   the sysctl can't be set until the module is loaded.

And this bonding stuff in particular wants to get into the
neighbour discovery state of the ipv6 module.  Therefore it's
not like we can split out a few functions into some kind
of "ipv6_helpers.ko" kernel module to eliminate the problem
either.

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[David Miller]

From: Brian Haley <brian.haley@hp.com>
Date: Tue, 17 Feb 2009 15:10:23 -0500

> Is it a common configuration to not allow a module to load like
> you're doing in modprobe.conf?  I don't know how hard it would be to
> rip this out into it's own bonding_ipv6.ko module, simply
> turning-off CONFIG_IPV6 seems better.

It's unfortunately how users get told to turn off ipv6.

There were some back-compat issues with how GLIBC emitted DNS requests
a few months ago that required turning off ipv6 completely otherwise
DNS requests would timeout.

Sticking an ipv6.ko module load disable into /etc/modprobe.conf
was the only tenable workaround.

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[David Miller]

From: Jay Vosburgh <fubar@us.ibm.com>
Date: Tue, 17 Feb 2009 13:06:28 -0800

> 	Putting the ipv6 bits into a different module might not help,
> either, because the "core" bonding code would still have the call to the
> ipv6 functions.  Unless there's some magic way to somehow know at
> runtime whether or not the ipv6 module is loaded, and only try to
> resolve those symbols if ipv6 is loaded.  That seems complicated.

This is a non-starter, as I described in one of my other replies.

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Valdis.Kletnieks]

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

On Tue, 17 Feb 2009 14:29:46 PST, David Miller said:
> Don't configure ipv6 into your kernel, really.
> 
> There is no other way to handle this.  If we want to support
> IPV6 layer things in the bonding driver, it is going to
> call helper functions in the ipv6 module and therefore must
> be able to load it and use functions in it.

What does a poor corporate user do if they're running a distro kernel that
was built with CONFIG_IPV6, but local security policy says "Disable IPv6
because we don't do it yet, or because it breaks mission-critical software
package XYZ?"  There's a *lot* of people who implement that by the "block
the ipv6 module from loading" trick.  And building a kernel that doesn't
include IPv6 may not be feasible due to vendor certification issues...

Heck, *I*'m almost in that boat - probably need to use bonded ethernet on some
servers because we can't get 10GigE, but the software used in the project the
servers were bought for blows chunks if it gets a whiff of an IPv6 address.
Ended up spending 3 weeks doing a massive kludgery of one sort in DNS for the
rest of the world, and equally massive lying in /etc/hosts for the hosts...
(Don't ask - it was long and ugly, and just disabling the module would have
saved me about 2.95 weeks of work, so I know where those people are coming
from...)


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

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[David Miller]

From: Valdis.Kletnieks@vt.edu
Date: Tue, 17 Feb 2009 23:41:16 -0500

> What does a poor corporate user do if they're running a distro kernel that
> was built with CONFIG_IPV6, but local security policy says "Disable IPv6
> because we don't do it yet, or because it breaks mission-critical software
> package XYZ?"  There's a *lot* of people who implement that by the "block
> the ipv6 module from loading" trick.  And building a kernel that doesn't
> include IPv6 may not be feasible due to vendor certification issues...
> 
> Heck, *I*'m almost in that boat - probably need to use bonded ethernet on some
> servers because we can't get 10GigE, but the software used in the project the
> servers were bought for blows chunks if it gets a whiff of an IPv6 address.
> Ended up spending 3 weeks doing a massive kludgery of one sort in DNS for the
> rest of the world, and equally massive lying in /etc/hosts for the hosts...
> (Don't ask - it was long and ugly, and just disabling the module would have
> saved me about 2.95 weeks of work, so I know where those people are coming
> from...)

Well, first of all, if you keep trying to push the box into the round
hole you get what you ask for :-)

Next, if it's just an issue of IPV6 traffic, install a packet
scheduler rule that rejects all packets with ethernet proto
ETH_P_IPV6

If openning up ipv6 sockets is problematic, that can be blocked
using the security layer, which your super-duper distro kernel
is guarenteed to have enabled. :-)

I'm sure there is someone who has legacy problems with ipv4
and that can't be disabled, and somehow people cope.  Amazing.

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Roland Dreier]

 > Next, if it's just an issue of IPV6 traffic, install a packet
 > scheduler rule that rejects all packets with ethernet proto
 > ETH_P_IPV6
 > 
 > If openning up ipv6 sockets is problematic, that can be blocked
 > using the security layer, which your super-duper distro kernel
 > is guarenteed to have enabled. :-)

This reminds me of a related issue that some users have run into with
IP-over-InfiniBand -- the IPoIB module also depends on ipv6 symbols if
ipv6 is enabled, so when ipoib is loaded then ipv6 gets loaded.  And
this causes a problem from some people in the IB case because assigning
an ipv6 address to the ipoib interface actually consumes some network
resources (the number of multicast groups that the network supports may
be limited and having a solicited node multicast group for each node may
use them all up).

Anyway, this leads to the folowing question: is there a way to prevent a
link-local ipv6 address from being configured automatically for the
ipoib interface?

Thanks,
  Roland

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Frank Blaschka]

We have the same issue with the qeth_l3 driver (it requires IPv6 symbols).
Distributors compile with IPv6 but some customes want to disable IPv6 without
building a custom kernel. If there would be a generic solution to address
this kind of runtime IPv6 dependencies this would be creat.  

Valdis.Kletnieks@vt.edu schrieb:
> On Tue, 17 Feb 2009 14:29:46 PST, David Miller said:
>> Don't configure ipv6 into your kernel, really.
>>
>> There is no other way to handle this.  If we want to support
>> IPV6 layer things in the bonding driver, it is going to
>> call helper functions in the ipv6 module and therefore must
>> be able to load it and use functions in it.
> 
> What does a poor corporate user do if they're running a distro kernel that
> was built with CONFIG_IPV6, but local security policy says "Disable IPv6
> because we don't do it yet, or because it breaks mission-critical software
> package XYZ?"  There's a *lot* of people who implement that by the "block
> the ipv6 module from loading" trick.  And building a kernel that doesn't
> include IPv6 may not be feasible due to vendor certification issues...
> 
> Heck, *I*'m almost in that boat - probably need to use bonded ethernet on some
> servers because we can't get 10GigE, but the software used in the project the
> servers were bought for blows chunks if it gets a whiff of an IPv6 address.
> Ended up spending 3 weeks doing a massive kludgery of one sort in DNS for the
> rest of the world, and equally massive lying in /etc/hosts for the hosts...
> (Don't ask - it was long and ugly, and just disabling the module would have
> saved me about 2.95 weeks of work, so I know where those people are coming
> from...)
> 

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Theodore Tso]

On Tue, Feb 17, 2009 at 09:29:19PM -0800, David Miller wrote:
> Next, if it's just an issue of IPV6 traffic, install a packet
> scheduler rule that rejects all packets with ethernet proto
> ETH_P_IPV6
> 
> If openning up ipv6 sockets is problematic, that can be blocked
> using the security layer, which your super-duper distro kernel
> is guarenteed to have enabled. :-)
> 
> I'm sure there is someone who has legacy problems with ipv4
> and that can't be disabled, and somehow people cope.  Amazing.

The reality is that there are far more people who have legacy problems
with ipv6 than ipv4 (which has been around and in active use for about
3 decades, after all), whereas ipv6 has been around and largely
ignored for about a decade.  :-/

I'll admit that I ran into some wierd sh*t problems with some open
source software or another failing mysteriously when IPv6 was enabled,
and I dealt with it by simply disabling IPv6 (yeah, I blocked the
module).  I was in a hurry, and it just didn't work, and I had better
thing to do than to spend time trying to debug why the presense of an
IPv6 enabled interface caused programs to misbehave in random ways.

I think I can pretty much guarantee that distro users will be
clamoring for a quick and easy way to block ipv6, and it's in our
interest to document the recomended way to block it that doesn't cause
weird problems with bonding, etc.

						- Ted

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Chuck Lever]

On Feb 18, 2009, at Feb 18, 2009, 8:55 AM, Theodore Tso wrote:
> On Tue, Feb 17, 2009 at 09:29:19PM -0800, David Miller wrote:
>> Next, if it's just an issue of IPV6 traffic, install a packet
>> scheduler rule that rejects all packets with ethernet proto
>> ETH_P_IPV6
>>
>> If openning up ipv6 sockets is problematic, that can be blocked
>> using the security layer, which your super-duper distro kernel
>> is guarenteed to have enabled. :-)
>>
>> I'm sure there is someone who has legacy problems with ipv4
>> and that can't be disabled, and somehow people cope.  Amazing.

Here's another "me too".

Kernel RPC support also has this problem.  We hit it just a couple of  
weeks ago now that we have IPv6 enabled NFS in prototype.  If PF_INET6  
listener creation fails (eg. because ipv6.ko is blacklisted), our  
workaround right now is to retry the listener socket creation with  
PF_INET.  There are plenty of somewhat rare corner cases that make  
this less than ideal.

> The reality is that there are far more people who have legacy problems
> with ipv6 than ipv4 (which has been around and in active use for about
> 3 decades, after all), whereas ipv6 has been around and largely
> ignored for about a decade.  :-/
>
> I'll admit that I ran into some wierd sh*t problems with some open
> source software or another failing mysteriously when IPv6 was enabled,
> and I dealt with it by simply disabling IPv6 (yeah, I blocked the
> module).  I was in a hurry, and it just didn't work, and I had better
> thing to do than to spend time trying to debug why the presense of an
> IPv6 enabled interface caused programs to misbehave in random ways.
>
> I think I can pretty much guarantee that distro users will be
> clamoring for a quick and easy way to block ipv6, and it's in our
> interest to document the recomended way to block it that doesn't cause
> weird problems with bonding, etc.

A better solution would be to design kernel and user space networking  
to handle this use case, instead of providing a workaround.  From the  
variety of comments I've heard, this use case is pretty common.

Considering the government mandates requiring IPv6 support (and the  
advertisements by Linux vendors claiming IPv6 support), IPv6 needs to  
become a first-class citizen in Linux in fairly short order.  It still  
feels a little piecemeal to me to be called "production ready."

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Vlad Yasevich]

Chuck Lever wrote:
> On Feb 18, 2009, at Feb 18, 2009, 8:55 AM, Theodore Tso wrote:
>> On Tue, Feb 17, 2009 at 09:29:19PM -0800, David Miller wrote:
>>> Next, if it's just an issue of IPV6 traffic, install a packet
>>> scheduler rule that rejects all packets with ethernet proto
>>> ETH_P_IPV6
>>>
>>> If openning up ipv6 sockets is problematic, that can be blocked
>>> using the security layer, which your super-duper distro kernel
>>> is guarenteed to have enabled. :-)
>>>
>>> I'm sure there is someone who has legacy problems with ipv4
>>> and that can't be disabled, and somehow people cope.  Amazing.
> 
> Here's another "me too".

And another "me too" for SCTP.  When IPv6 is turned on in the kernel
config file, we include the necessary pieces into the SCTP module and
sctp.ko will not load if ipv6.ko is blacklisted.

Having worked in other environments where ipv6 has to be explicitly
enabled per interface, I've thought that this level of control was
always missing from linux.  Being able to configure only the interface
that users want seems like a good thing to have.
Would a module parameter that disables ipv6 or at least addrconf be
enough of a solution?

-vlad

> 
> Kernel RPC support also has this problem.  We hit it just a couple of
> weeks ago now that we have IPv6 enabled NFS in prototype.  If PF_INET6
> listener creation fails (eg. because ipv6.ko is blacklisted), our
> workaround right now is to retry the listener socket creation with
> PF_INET.  There are plenty of somewhat rare corner cases that make this
> less than ideal.
> 
>> The reality is that there are far more people who have legacy problems
>> with ipv6 than ipv4 (which has been around and in active use for about
>> 3 decades, after all), whereas ipv6 has been around and largely
>> ignored for about a decade.  :-/
>>
>> I'll admit that I ran into some wierd sh*t problems with some open
>> source software or another failing mysteriously when IPv6 was enabled,
>> and I dealt with it by simply disabling IPv6 (yeah, I blocked the
>> module).  I was in a hurry, and it just didn't work, and I had better
>> thing to do than to spend time trying to debug why the presense of an
>> IPv6 enabled interface caused programs to misbehave in random ways.
>>
>> I think I can pretty much guarantee that distro users will be
>> clamoring for a quick and easy way to block ipv6, and it's in our
>> interest to document the recomended way to block it that doesn't cause
>> weird problems with bonding, etc.
> 
> A better solution would be to design kernel and user space networking to
> handle this use case, instead of providing a workaround.  From the
> variety of comments I've heard, this use case is pretty common.
> 
> Considering the government mandates requiring IPv6 support (and the
> advertisements by Linux vendors claiming IPv6 support), IPv6 needs to
> become a first-class citizen in Linux in fairly short order.  It still
> feels a little piecemeal to me to be called "production ready."
> 
> -- 
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
> -- 
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Brian Haley]

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

Vlad Yasevich wrote:
> Having worked in other environments where ipv6 has to be explicitly
> enabled per interface, I've thought that this level of control was
> always missing from linux.  Being able to configure only the interface
> that users want seems like a good thing to have.
> Would a module parameter that disables ipv6 or at least addrconf be
> enough of a solution?

There does seem to be a sysctl for it, just doesn't seem to work. 
Possible patch below.

This actually brings up the issue that the "all" ipv6 sysctl, for 
example net.ipv6.conf.all.disable_ipv6, doesn't actually do anything (at 
least it didn't seem to for me).  Maybe it's time to fix that too to be 
like IPv4, things like IN_DEV_RPFILTER() and friends aren't looking so 
bad...

I tested this patch on lo and a few Ethernet devices and saw no IPv6 
addresses.  Don't know if EPERM is the right errno since we don't know 
if the user set this or DAD failed.


The disable_ipv6 knob was meant to be used for the kernel to disable 
IPv6 on an interface when DAD failed for the link-local address based on 
the MAC, but we should also be able to administratively disable it on an 
interface, or the entire system.  This patch fixes the per-interface 
problem.

Signed-off-by: Brian Haley <brian.haley@hp.com>

[-- Attachment #2: noipv6.patch --]
[-- Type: text/x-diff, Size: 421 bytes --]

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 03e2a1a..9bc761f 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -603,6 +603,11 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr, int pfxlen,
 		goto out2;
 	}
 
+	if (idev->cnf.disable_ipv6) {
+		err = -EPERM;
+		goto out2;
+	}
+
 	write_lock(&addrconf_hash_lock);
 
 	/* Ignore adding duplicate addresses on an interface */

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[John Dykstra]

On Wed, 2009-02-18 at 14:57 -0500, Brian Haley wrote: 
> Vlad Yasevich wrote:
> > Having worked in other environments where ipv6 has to be explicitly
> > enabled per interface, I've thought that this level of control was
> > always missing from linux.  
> 
> There does seem to be a sysctl for it, just doesn't seem to work.

While this sysctl is definitely useful, I don't think it meets the needs
of those users and distributions that are currently blacklisting the
ipv6 module.  Even if you disable IPv6 on all interfaces, apps will
still be able to create AF_INET6 sockets, and thus some apps will break
or do inappropriate things because there isn't real IPv6 connectivity.

I've tried to put together an RFC patch that turned off all
externally-visible IPv6 behavior that could break something, but I keep
running into distasteful choices.

The current default behavior must be preserved--if you drop this patch
into an existing distribution, the IPv6 stack must come up the way it
always has.  Thus the knob (let's call it ip6_disable) must default
false.

It seems desirable to make this a per-net-namespace knob.  But that
means each new net will be initialized before the distribution has a
chance to disable the IPv6 part.  This will lead to neighbor solicits
going out for link-local addresses, which some people can't accept.

The only alternative I can think of is to make it a module parameter,
which would leverage people's current habit to disable IPv6 via the
module configuration files, but doesn't fit well into a virtualized
world.

Exactly what to disable is unclear too.  Turning off neighbor and router
solicits, responding to same, etc.--almost certainly.  Refusing to
create AF_INET6 sockets--definitely.  Erroring on ioctl() and netlink
API calls related to IPv6--probably.  Hiding /proc entries for IPv6--I
don't know.  

Ideally, once ip6_disable was set true, every API, /proc and /sys
entries, etc. would look just like the ipv6 module was not loaded.  But
to do this, while still initializing most of the IPv6 code (so that
those hooks from other modules won't do unexpected things) is very
invasive.

So it seems to me that the only practical solution is to live with
blacklisting module ipv6 until the apps are fixed and sending IPv6
packets isn't considered a crime.

  --  John

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Stephen Hemminger]

On Wed, 18 Feb 2009 21:21:07 +0000
John Dykstra <john.dykstra1@gmail.com> wrote:

> On Wed, 2009-02-18 at 14:57 -0500, Brian Haley wrote: 
> > Vlad Yasevich wrote:
> > > Having worked in other environments where ipv6 has to be explicitly
> > > enabled per interface, I've thought that this level of control was
> > > always missing from linux.  
> > 
> > There does seem to be a sysctl for it, just doesn't seem to work.
> 
> While this sysctl is definitely useful, I don't think it meets the needs
> of those users and distributions that are currently blacklisting the
> ipv6 module.  Even if you disable IPv6 on all interfaces, apps will
> still be able to create AF_INET6 sockets, and thus some apps will break
> or do inappropriate things because there isn't real IPv6 connectivity.
> 
> I've tried to put together an RFC patch that turned off all
> externally-visible IPv6 behavior that could break something, but I keep
> running into distasteful choices.
> 
> The current default behavior must be preserved--if you drop this patch
> into an existing distribution, the IPv6 stack must come up the way it
> always has.  Thus the knob (let's call it ip6_disable) must default
> false.
> 
> It seems desirable to make this a per-net-namespace knob.  But that
> means each new net will be initialized before the distribution has a
> chance to disable the IPv6 part.  This will lead to neighbor solicits
> going out for link-local addresses, which some people can't accept.
> 
> The only alternative I can think of is to make it a module parameter,
> which would leverage people's current habit to disable IPv6 via the
> module configuration files, but doesn't fit well into a virtualized
> world.
> 
> Exactly what to disable is unclear too.  Turning off neighbor and router
> solicits, responding to same, etc.--almost certainly.  Refusing to
> create AF_INET6 sockets--definitely.  Erroring on ioctl() and netlink
> API calls related to IPv6--probably.  Hiding /proc entries for IPv6--I
> don't know.  
> 
> Ideally, once ip6_disable was set true, every API, /proc and /sys
> entries, etc. would look just like the ipv6 module was not loaded.  But
> to do this, while still initializing most of the IPv6 code (so that
> those hooks from other modules won't do unexpected things) is very
> invasive.
> 
> So it seems to me that the only practical solution is to live with
> blacklisting module ipv6 until the apps are fixed and sending IPv6
> packets isn't considered a crime.
> 
>   --  John

There are also ipv6 purists who would like to see the same mechanism
exist to force ipv6 only (no ipv4). So any long term solution should
support both.

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[David Miller]

From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Wed, 18 Feb 2009 13:33:42 -0500

> Would a module parameter that disables ipv6 or at least addrconf be
> enough of a solution?

We have it, it's just that (as others have stated) it doesn't
prevent IPV6 sockets from being openned by applications.

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Vlad Yasevich]

David Miller wrote:
> From: Vlad Yasevich <vladislav.yasevich@hp.com>
> Date: Wed, 18 Feb 2009 13:33:42 -0500
> 
>> Would a module parameter that disables ipv6 or at least addrconf be
>> enough of a solution?
> 
> We have it, it's just that (as others have stated) it doesn't
> prevent IPV6 sockets from being openned by applications.
> 

Is that what people really want to block?

Or do they want to prevent the use of IPv6 in environments where
IPv6 is not supported?  If it's this case, then simply not configuring
any IPv6 addresses on the system interfaces will make it seem as if
IPv6 is not there.

Without IPv6 addresses, AF_INET6 sockets are the same as AF_INET.
I really see no reason to block them.  Any legacy apps that people
might worry about don't use this type socket any way.

One doesn't even need to worry about processing IPv6 traffic,
since the system would never join any IPv6 multicast groups and thus
would never see 99% of the traffic.

-vlad

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Herbert Xu]

Theodore Tso <tytso@mit.edu> wrote:
> 
> I think I can pretty much guarantee that distro users will be
> clamoring for a quick and easy way to block ipv6, and it's in our
> interest to document the recomended way to block it that doesn't cause
> weird problems with bonding, etc.

We already have a way:

echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Herbert Xu]

Brian Haley <brian.haley@hp.com> wrote:
> 
> There does seem to be a sysctl for it, just doesn't seem to work. 

OK we should definitely fix that.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Randy Dunlap]

Andrey Borzenkov wrote:
> Forward to bonding and netdev
> 
> On 17 of February 2009 11:52:32 J.A. Magallón wrote:
>> Hi all...
>>
>> Don't know if this is specific for -rc5, I have jumped from 28.4 to
>> 29-rc5. In this latest kernel, I can not install 'bonding' module if
>> 'ipv6' is disabled to load via modprobe.conf:
>>
>> install ipv6 /bin/true
>>
>> Trying bonding gives this dmesg:
>>
>> bonding: Unknown symbol ndisc_build_skb
>> bonding: Unknown symbol in6_dev_finish_destroy
>> bonding: Unknown symbol ndisc_send_skb
>> bonding: Unknown symbol unregister_inet6addr_notifier
>> bonding: Unknown symbol register_inet6addr_notifier
>>
>> Commenting the line in modprobe.conf makes things smooth again.
>> We can not disable ipv6 anymore ?
>>
> 
> If IPv6 is disable in kernel config bonding loads. But I think it is 
> regression, it should be possible to disable IPv6 if not required.

Just for clarification, is this a run-time (module load-time) error
but not a build error?

-- 
~Randy

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Andrey Borzenkov]

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

On 19 of February 2009 21:15:07 Randy Dunlap wrote:
> Andrey Borzenkov wrote:
> > Forward to bonding and netdev
> >
> > On 17 of February 2009 11:52:32 J.A. Magallón wrote:
> >> Hi all...
> >>
> >> Don't know if this is specific for -rc5, I have jumped from 28.4
> >> to 29-rc5. In this latest kernel, I can not install 'bonding'
> >> module if 'ipv6' is disabled to load via modprobe.conf:
> >>
> >> install ipv6 /bin/true
> >>
> >> Trying bonding gives this dmesg:
> >>
> >> bonding: Unknown symbol ndisc_build_skb
> >> bonding: Unknown symbol in6_dev_finish_destroy
> >> bonding: Unknown symbol ndisc_send_skb
> >> bonding: Unknown symbol unregister_inet6addr_notifier
> >> bonding: Unknown symbol register_inet6addr_notifier
> >>
> >> Commenting the line in modprobe.conf makes things smooth again.
> >> We can not disable ipv6 anymore ?
> >
> > If IPv6 is disable in kernel config bonding loads. But I think it
> > is regression, it should be possible to disable IPv6 if not
> > required.
>
> Just for clarification, is this a run-time (module load-time) error
> but not a build error?

Yes, this is run-time error. If IPV6 is disabled during kernel build, 
everything works; but the error was seen on distribution kernel which 
includes IPV6.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Jay Vosburgh]

Randy Dunlap <randy.dunlap@oracle.com> wrote:

>Andrey Borzenkov wrote:
>> Forward to bonding and netdev
>> 
>> On 17 of February 2009 11:52:32 J.A. Magallón wrote:
>>> Hi all...
>>>
>>> Don't know if this is specific for -rc5, I have jumped from 28.4 to
>>> 29-rc5. In this latest kernel, I can not install 'bonding' module if
>>> 'ipv6' is disabled to load via modprobe.conf:
>>>
>>> install ipv6 /bin/true
>>>
>>> Trying bonding gives this dmesg:
>>>
>>> bonding: Unknown symbol ndisc_build_skb
>>> bonding: Unknown symbol in6_dev_finish_destroy
>>> bonding: Unknown symbol ndisc_send_skb
>>> bonding: Unknown symbol unregister_inet6addr_notifier
>>> bonding: Unknown symbol register_inet6addr_notifier
>>>
>>> Commenting the line in modprobe.conf makes things smooth again.
>>> We can not disable ipv6 anymore ?
>>>
>> 
>> If IPv6 is disable in kernel config bonding loads. But I think it is 
>> regression, it should be possible to disable IPv6 if not required.
>
>Just for clarification, is this a run-time (module load-time) error
>but not a build error?

	Yes, module load error, but not a build error.

	The build with CONFIG_IPV6 is fine, and bonding loads fine as
long as ipv6 is loaded.  The issue arises when the ipv6 module is
prevented from loading; in that case, bonding cannot load because it now
requires functionality from ipv6.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: Bonding tied to IPV6 in 29-rc5

[Jan Engelhardt]

On Tuesday 2009-02-17 09:52, J.A. Magallón wrote:

>Hi all...
>
>Don't know if this is specific for -rc5, I have jumped from 28.4 to 29-rc5.
>In this latest kernel, I can not install 'bonding' module if 'ipv6' is
>disabled to load via modprobe.conf:
>
>install ipv6 /bin/true
>
>Trying bonding gives this dmesg:
>
>bonding: Unknown symbol ndisc_build_skb
>bonding: Unknown symbol in6_dev_finish_destroy
>bonding: Unknown symbol ndisc_send_skb
>bonding: Unknown symbol unregister_inet6addr_notifier
>bonding: Unknown symbol register_inet6addr_notifier
>
>Commenting the line in modprobe.conf makes things smooth again.
>We can not disable ipv6 anymore ?

Well, given ipv6 is now a runtime dependency when compiled
with CONFIG_IPV6={m,y}, it seems about right what you see.
I would not call this a regression.

$ modinfo bonding
filename:       /lib/modules/2.6.29-rc6-jen77-rt/kernel/bonding.ko.gz
author:         Thomas Davis, tadavis@lbl.gov and many others
description:    Ethernet Channel Bonding Driver, v3.5.0
version:        3.5.0
license:        GPL
srcversion:     752CFD14F79DC79CF4BFB2E
depends:        ipv6
                ^^^^

Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

[Jan Engelhardt]

On Tuesday 2009-02-17 23:24, Jay Vosburgh wrote:
>Brian Haley <brian.haley@hp.com> wrote:
>
>	I don't see any reason to change the IPv4 bits;
>
>there won't ever be a case of ipv4 not being loaded,

I would not be so sure of that.

>>> 	To answer your question, I have come across this (aliasing ipv6
>>> to nothing in modprobe.conf to disable IPv6) from time to time, but
>>> didn't think of it when the NA code was added to bonding.
>>
>>So I guess I'll start hacking the above, unless someone has a better
>>suggestion.
>
>	Well, I think this is pretty heinous, but I don't have a better
>idea at the moment.

IMO, a better solution could be to add a dummy ipv6 module that returns 
-EOPNOTSOPP or appropriate for most calls.