All of lore.kernel.org
 help / color / mirror / Atom feed
* Linux 3.0-rc6 ..
@ 2011-07-04 23:09 Linus Torvalds
  2011-07-06 15:27 ` Arkadiusz Miśkiewicz
  2011-07-11  6:03 ` Al Viro
  0 siblings, 2 replies; 14+ messages in thread
From: Linus Torvalds @ 2011-07-04 23:09 UTC (permalink / raw)
  To: Linux Kernel Mailing List

and a happy Independence Day to all the US kernel people out there.

There is not a lot to be said about -rc6. The biggest part by far is
the inclusion of the intel isci driver - I was admittedly a bit
doubtful about it, but it's not like it is going to cause regressions
for any existing Linux users, so whatever.

And quite frankly, Christoph Hellwig has now _twice_ said good things
about that driver, which is pretty unusual. It might mean that the
driver is great. Of course, it's way more likely that space aliens are
secretly testing their happy drugs on Christoph. Or maybe he's just
naturally mellowing.

Other than the isci driver, the rest really is just lots of random
small stuff. It's getting to the point where I'm thinking I should
just release 3.0, because it's been pretty quiet, and the fixes
haven't been earth-shakingly exciting. Some drm (radeon and intel)
fixes might be noticeable to more people, the rest would tend to be
pretty esoteric.

And so, I'm off to make s'mores,

                  Linus

---
Adam Gruchala (2):
      isci: merge phy substates
      isci: Added support for C0 to SCU Driver

Alan Cox (1):
      8250_pci: Fix missing const from merges

Alan Stern (3):
      USB: change maintainership of ohci-hcd and ehci-hcd
      USB: don't let the hub driver prevent system sleep
      USB: don't let errors prevent system sleep

Alex Deucher (4):
      drm/radeon/kms: increase rom size for atrm method
      drm/radeon/kms: Fix chremap setup on RV770 CE
      drm/radeon/kms: use correct reg on fusion when reading back mem config
      drm/radeon/kms: fix typo in cayman reg offset

Alex He (2):
      xHCI 1.0: Force Stopped Event(FSE)
      xHCI 1.0: Incompatible Device Error

Andrew Morton (1):
      drivers/base/platform.c: don't mark
platform_device_register_resndata() as __init_or_module

Artur Wojcik (1):
      isci: unify isci_host data structures

Arvid Brodin (1):
      usb/isp1760: Fix bug preventing the unlinking of control urbs

Avi Kivity (1):
      KVM: x86 emulator: fix %rip-relative addressing with immediate
source operand

Axel Lin (1):
      watchdog: gef_wdt: fix MODULE_ALIAS

Bartosz Barcinski (2):
      isci: sparse warnings cleanup
      isci: audit usage of BUG_ON macro in isci driver

Ben Skeggs (1):
      Revert "drm/nvc0: recognise 0xdX chipsets as NV_C0"

Ben Widawsky (2):
      drm/i915: forcewake fix after reset
      drm/i915: Don't call describe_obj on NULL pointers

Boojin Kim (1):
      ARM: SAMSUNG: serial: Fix on handling of one clock source for UART

Brian King (1):
      [SCSI] ibmvfc: Fix Virtual I/O failover hang

Chris Wilson (2):
      drm/i915: Use chipset-specific irq installers
      drm/i915/overlay: Fix unpinning along init error paths

Christian Dietrich (2):
      powerpc/rtas-rtc: remove sideeffects of printk_ratelimit
      arch/powerpc: use printk_ratelimited instead of printk_ratelimit

Christoph Hellwig (7):
      isci: remove mmio wrappers
      isci: remove base_controller abstraction
      isci: remove base_request abstraction
      isci: kill dead data structurs in scic_io_request.h
      isci: simplify request state handlers
      isci: simplify dma coherent allocation
      isci: remove scic_controller state handlers

Clemens Ladisch (1):
      hwmon: (k10temp) Update documentation for Fam12h

Damian Hobson-Garcia (1):
      fbdev: sh_mobile_meram: Correct pointer check for YCbCr chroma plane

Dan Carpenter (1):
      net/usb/kalmia: signedness bug in kalmia_bind()

Dan Williams (142):
      isci: Intel(R) C600 Series Chipset Storage Control Unit Driver
      isci: kill SCI_IO_REQUEST_DATA_DIRECTION
      isci: cleanup core consolidation leftovers
      isci: kill a callback cast
      isci: remove SCIC_DEBUG_ENABLED, and fixup an odd macro
      isci: bypass scic_controller_get_handler_methods()
      isci: cleanup "starting" state handling
      isci: implement error isr
      isci: advertise linkrate
      isci: debug fixes
      isci: phy state machine cleanup step1
      isci: clean up remaining silicon revision ifdefs in phy init
      isci: fix sas address reporting
      isci: rework timer api
      isci: fix hang after target reset
      isci: pad stp and smp request sizes
      isci: enable isci for dmar builds
      isci: kill isci_host list in favor of an array
      isci: remove sci_device_handle
      isci: kill "host quiesce" mechanism
      isci: replace isci_remote_device completion with event queue
      isci: preallocate remote devices
      isci: replace remote_device_lock  with scic_lock
      isci: cleanup debug leftovers in isci.h
      isci: Errors in the submit path for SATA devices manage the ap lock.
      isci: add "isci_id" attribute
      isci: fix incorrect assumptions about task->dev and
task->dev->port being NULL
      isci: task.h compile and checkpatch fixes
      isci: reset hardware at init
      isci: Add support for probing OROM for OEM params
      isci: fixup with testing from isci OROM in BIOS
      isci: fix oem parameter initialization and mode detection
      isci: fix apc mode definition
      isci: fix a build warning
      isci: reorder init to cleanup unneeded declarations
      isci: kill some long macros
      isci: namespacecheck cleanups
      isci: remove unused "remote_device_started"
      isci: cleanup isci_remote_device[_not]_ready interface
      isci: fix fragile/conditional isci_host lookups
      isci: replace sci_sas_link_rate with sas_linkrate
      isci: fix oem parameter header definition
      isci: validate oem parameters early, and fallback
      isci: rely on irq core for intx multiplexing, and silence screaming intx
      isci: make a remote_node_context a proper member of a remote_device
      isci: remove rnc->device back pointer
      isci: unify remote_device data structures
      isci: move remote_device handling out of the core
      isci: cleanup remote device construction and comments
      isci: kill smp_discover_response_protocols in favor of
domain_device.dev_type
      isci: kill smp_discover_response
      isci: remove usage of sci_sas_address in scic_sds_remote_device
      isci: remove scic_sds_remote_device_get_port_index
      isci: allow fallback to option-rom if efi variable retrieval fails
      isci: merge remote_device substates into a single state machine
      isci: kill scic_remote_device_get_connection_rate
      isci: fix remote_device start_io regressions
      isci: unify remote_device start_handlers
      isci: unify remote_device stop_handlers
      isci: kill remote_device fail_handler
      isci: unify remote_device destruct_handlers
      isci: unify remote_device reset_handlers
      isci: unify remote_device reset_complete_handlers
      isci: unify remote_device start_io_handlers
      isci: unify remote_device complete_io_handlers
      isci: kill remote_device continue_io_handler
      isci: unify remote_device start_task_handlers
      isci: kill remote_device complete_task_handler
      isci: unify remote_device suspend_handlers
      isci: kill remote_device resume_handler
      isci: unify remote_device event_handlers
      isci: unify remote_device frame_handlers
      isci: kill scic_sds_remote_device.state_handlers
      isci: remove compile-time (Kconfig) silicon configuration
      isci: fix ata locking
      isci: implement I_T_nexus_reset
      isci: unify phy data structures
      isci: unify port data structures
      isci: move stp request info to scic_sds_request
      isci: make sgl explicit/aligned request object member
      isci: move task context alignment from run-time to compile time
      isci: make command/response iu explicit request object members
      isci: unify request data structures
      isci: unify constants
      isci: move core/controller to host
      isci: uplevel register hardware data structures and unsolicited
frame handling
      isci: uplevel state machine
      isci: uplevel request infrastructure
      isci: uplevel phy infrastructure
      isci: uplevel port infrastructure
      isci: merge ssp task management substates into primary state machine
      isci: merge smp request substates into primary state machine
      isci: merge stp request substates into primary state machine
      isci: unify request abort handlers
      isci: unify request frame handlers
      isci: remove request task context completion state handler
      isci: remove the completion and event state handlers
      isci: unify phy start handlers
      isci: unify phy stop handlers
      isci: unify phy reset handlers
      isci: remove phy destruct handlers
      isci: unify phy frame handlers
      isci: unify phy event handlers
      isci: unify phy consume_power handlers
      isci: clarify phy to port lookups
      isci: unify port start_io and complete_io handlers
      isci: unify rnc event handlers
      isci: unify rnc destruct handlers
      isci: unify rnc suspend/resume handlers
      isci: unify rnc start{io|task} handlers
      isci: add some type safety to the state machine interface
      isci: remove 'min memory' infrastructure
      isci: fix isci_terminate_pending() list management
      isci: cleanup/optimize pool implementation
      isci: cleanup tag macros
      isci: cleanup/optimize queue increment macros
      isci: cleanup request allocation
      isci: fix ssp response iu buffer size in isci_tmf
      isci: atomic device lookup and reference counting
      isci: kill isci_remote_device_change_state()
      isci: kill device_sequence
      isci: fix smp response frame overrun
      isci: fix dma_unmap_sg usage
      isci: fix support for arbitrarily large smp requests
      isci: fix isci_task_execute_tmf completion
      isci: fix frame received locking
      isci: unify can_queue tracking on the tci_pool, uplevel tag assignment
      isci: combine request flags
      isci: preallocate requests
      isci: rename / clean up scic_sds_stp_request
      isci: unify isci_request and scic_sds_request
      isci: unify isci_phy and scic_sds_phy
      isci: fix scic_sds_remote_device_terminate_requests
      isci: unify isci_port and scic_sds_port
      isci: unify isci_remote_device and scic_sds_remote_device
      isci: unify isci_host and scic_sds_controller
      isci: retire scic_sds_ and scic_ prefixes
      isci: kill 'get/set' macros
      isci: merge sata.[ch] into request.c
      isci: merge scu_unsolicited_frame.h into unsolicited_frame_control.h
      isci: cleanup silicon revision detection
      isci: pare back error messsages

Daniel J Blueman (1):
      vesafb: fix memory leak

Dave Jiang (38):
      isci: removing unused loglevel module param
      isci: Move firmware loading to per PCI device
      isci: Removed special macros that does 64bit address math
      isci: Make the driver copy data directly from and to sg for PIO
      isci: have the driver use native SG calls and DMA-API
      isci: Change event notify calls from scic_cb_* to isci_event_*
      isci: Removing deprecated functions
      isci: Adding support for phy enable and disable
      isci: Cleanup warning messages for phy resets
      isci: Adding EFI variable skeletal support
      isci: update efi variable name and guid
      isci: copy the oem parameters instead of assign
      isci: Fixup for OEM parameter EFI variable retrieval
      isci: exposing user parameters via module params
      isci: Remove event_* calls as they are just wrappers
      isci: Remove "screaming" data types
      isci: replace this_* and the_* variables with more meaningful names
      isci: removing non-working ATAPI code
      isci: Remove excessive log noise with expander hot-unplug
      isci: Removing unused define SCIC_SDS_4_ENABLED
      isci: Convert SATA fis data structures to Linux native
      isci: Convert ATA defines to Linux native defines
      isci: Convert SAS identify address frame to Linux Native format
      isci: Collapsing of phy_type data structure
      isci: renaming sas_capabilities to scic_phy_cap
      isci: Fixup SSP command IU and task IU
      isci: Convert of sci_ssp_response_iu to ssp_response_iu
      isci: Fixup of smp request
      isci: Converting smp_response to Linux native smp_resp
      isci: remove redundant copies of IAF
      isci: fixup SAS iaf protocols data structure
      isci: Remove SCIC_SWAP_DWORD()
      isci: Using Linux SSP frame header
      isci: removing intel_*.h headers
      isci: Removing unnecessary functions in request.c
      isci: removing the kmalloc in smp request construct
      isci: Retrieve the EFI variable for OEM parameter
      isci: Removing unused variables compiler warnings

Dave Jones (1):
      usbnet: Remove over-broad module alias from zaurus.

David Henningsson (2):
      ALSA: HDA: Add a new Conexant codec ID (506c)
      ALSA: HDA: Add model=auto quirk for Acer Aspire 3830TG

David S. Miller (1):
      net+crypto: Use vmalloc for zlib inflate buffers.

Edmund Nadolski (17):
      isci: remove unused SC_LIBRARY_HANDLE_T typedef
      isci: remove SCI_INVALID_HANDLE
      isci: kill sci_types.h
      isci: enable interrupts during controller start, and flush discovery
      isci: remove scic_controller_get_handler_methods and ilk
      isci: kill scic_controller_get_port_handle function
      isci: remove scic_sds_port_increment_request_count
      isci: replace isci_timer list with proper embedded timers
      isci: convert port config agent timer to sci_timer
      isci: convert phy sata_timeout_timer to sci_timer
      isci: convert power control timer to sci_timer
      isci: convert scic_timeout_timer to sci_timer
      isci: convert phy_startup_timer to sci_timer
      isci: Remove tmf timeout_timer
      isci: remove isci_timer interface
      isci: state machine cleanup
      isci: additional state machine cleanup

Florian Fainelli (3):
      watchdog: mtx1-wdt: request gpio before using it
      watchdog: mtx1-wdt: fix GPIO toggling
      watchdog: mtx1-wdt: fix section mismatch

Francois Romieu (1):
      r8169: fix wrong register use.

Gabor Juhos (1):
      USB: ehci-ath79: fix a NULL pointer dereference

Geert Uytterhoeven (1):
      Staging: iio: Make IIO depend on GENERIC_HARDIRQS

Goldwyn Rodrigues (1):
      RDMA: Check for NULL mode in .devnode methods

Greg Kroah-Hartman (3):
      Staging: brcm80211: disable drivers for PPC platforms
      Staging: brcm80211: disable drivers except for X86 or MIPS platforms
      Staging: comedi: fix build breakages on some platforms

Guennadi Liakhovetski (1):
      ARM: mach-shmobile: make a struct in board-ap4evb.c static

Guenter Roeck (4):
      hwmon: (pmbus) Drop check for PMBus revision register in probe function
      hwmon: (adm1275) Free allocated memory if probe function fails
      hwmon: (pmbus) Improve fan detection
      hwmon: (pmbus) Auto-detect temp2 and temp3 registers/attributes

Hans de Goede (2):
      hwmon: Use <> rather than () around my e-mail address
      hwmon: (f71882fg) Add support for the F71869A

Hans-Christian Egtvedt (3):
      ALSA: atmel - update author email for ABDAC, AC97C and AT73C213
      watchdog: update author email for at32ap700x_wdt
      MAINTAINERS: update AVR32 and AT32AP maintainers

Havard Skinnemoen (1):
      isci: Initialize proc_name field in scsi_host_template

Henrik Ahlgren (1):
      CREDITS: Fix typo

Henryk Dembkowski (6):
      isci: remote device and node cleanup step1
      isci: coding style changes for remote device
      isci: c99 tables cleanup step1
      isci: coding style changes for remote device
      isci: Move transport layer registers from port to phy
      isci: add support for 2 more oem parmeters

Herbert Xu (1):
      bridge: Only flood unregistered groups to routers

Ilia Kolomisnky (1):
      Bluetooth: Fix L2CAP connection establishment

J Freyensee (3):
      pti: double-free security PTI fix
      pti: ENXIO error case memory leak PTI fix.
      pti: PTI semantics fix in pti_tty_cleanup.

Jacek Danecki (2):
      isci: Add support for user parameters in SCIC layer
      isci: rnc state machine table c99 conversion

James Bottomley (1):
      [SCSI] isci: fix checkpatch errors

Jean Delvare (3):
      i2c-taos-evm: Fix log messages
      hwmon: (emc6w201) Properly handle all errors
      hwmon-vid: Fix typo in VIA CPU name

Jean-Christophe PLAGNIOL-VILLARD (3):
      at91: fix at91_set_serial_console: use platform device id
      atmel_serial: fix internal port num
      at91: fix udc, ehci and mmc clock device name for cap9/9g45/9rl

Jeff Layton (1):
      cifs: set socket send and receive timeouts before attempting connect

Jeff Skirvin (27):
      isci: isci_request_cleanup_completed_loiterer checks task before task_done
      isci: Changes in isci_host_completion_routine
      isci: fix completion / abort path.
      isci: Any reset indicated on an I/O completion escalates it to
the error path.
      isci: save the i/o tag outside the scic request structure.
      isci: Cleaning up task execute path.
      isci: Code review change for completion pointer cleanup.
      isci: Termination handling cleanup, added termination timeouts.
      isci: Fix TMF build for SAS/SATA LUN reset cases.
      isci: Fixed BUG_ON in isci_abort_task_process_cb callback.
      isci: Always set response/status for requests going into the error path.
      isci: All pending requests are terminated before stopping the device.
      isci: don't hold scic_lock over calls to sas_task_abort()
      isci: Properly handle requests in the "aborting" state.
      isci: Free host lock for SATA/STP abort escalation at submission time.
      isci: Fix use of SATA soft reset state machine.
      isci: Qualify when the host lock is managed for STP/SATA callbacks.
      isci: Move the reset delay after the remote node resumption.
      isci: filter broadcast change notifications during SMP phy resets
      isci: Add decode for SMP request retry error condition
      isci: Requests that do not start must be set to "complete"
      isci: Handle timed-out request terminations correctly
      isci: Explicitly decode remote node ready and suspended states
      isci: Hard reset failure will link reset all phys in the port
      isci: Disable link layer hang detection
      isci: Terminate dev requests on FIS err bit rx in NCQ
      isci: Device reset should request sas_phy_reset(phy, true)

Jesper Juhl (3):
      USB: TI 3410/5052 USB Serial Driver: Fix mem leak when firmware
is too big.
      watchdog: Intel SCU Watchdog: Fix build and remove duplicate code
      Update version number references in README

Jesse Barnes (4):
      drm/i915: split page flip queueing into per-chipset functions
      drm/i915: add Ivy Bridge page flip support
      drm/i915: move IRQ function table init to i915_irq.c
      drm/i915: apply HWSTAM writes to Ivy Bridge as well

Jiri Slaby (2):
      TTY: ldisc, do not close until there are readers
      TTY: ntty, add one more sanity check

Joachim Eastwood (1):
      at91: Use "pclk" as con_id on at91cap9 and at91rm9200

Johan Hedberg (1):
      Bluetooth: Fix accepting connect requests for defer_setup

John (Jay) Hernandez (1):
      cxgb3: skb_record_rx_queue now records the queue index relative
to the net_device.

Julian Anastasov (1):
      netfilter: Fix ip_route_me_harder triggering ip_rt_bug

K. Y. Srinivasan (2):
      Connector: Set the CN_NETLINK_USERS correctly
      Connector: Correctly set the error code in case of success when
dispatching receive callbacks

Keith Packard (1):
      drm/i915: Hold struct_mutex during i915_save_state/i915_restore_state

Kevin Hilman (1):
      PM: Documentation: fix typo: pm_runtime_idle_sync() doesn't exist.

Kim Phillips (1):
      crypto: caam - fix operator precedence in shared descriptor allocation

Konrad Rzeszutek Wilk (2):
      xen/mmu: Fix for linker errors when CONFIG_SMP is not defined.
      xen/pci: Use the INT_SRC_OVR IRQ (instead of GSI) to preset the
ACPI SCI IRQ.

Kuninori Morimoto (1):
      ARM: mach-shmobile: mackerel: change usbhs devices order

Larry Finger (2):
      rtlwifi: rtl8192se: Handle duplicate PCI ID 0x10ec:0x8192
conflict with r8192e_pci
      rtl8192cu: Fix missing firmware load

Lennart Sorensen (1):
      serial: ioremap warning fix for jsm driver.

Linus Torvalds (2):
      ahci: change 'masking port_map' printk to KERN_WARNING level
      Linux 3.0-rc6

Loïc Minier (1):
      fbdev: amba: Link fb device to its parent

Luiz Augusto von Dentz (1):
      Bluetooth: Fix L2CAP security check

Maarten Lankhorst (1):
      xhci: Add reset on resume quirk for asrock p67 host

Maciej Patelczyk (10):
      isci: Implement SCU AFE recipe 10.
      isci: Removed struct sci_base_object from state machine.
      isci: Removed sci_base_object from scic_sds_controller.
      isci: Removed sci_base_object from scic_sds_phy.
      isci: Removed sci_base_object from scic_sds_port.
      isci: Removed sci_base_object from scic_sds_remote_device.
      isci: Removed sci_base_object from scic_sds_remote_node_context.
      isci: Removed sci_base_object from scic_sds_request.
      isci: Removed sci_object.h from project.
      isci: possible buffer overflow in isci_parse_oem_parameters fixed

Maciej Trela (3):
      isci: remove base_remote_device abstraction
      isci: remove base_port abstraction
      isci: remove base_phy abstraction

Marc Kleine-Budde (1):
      net/can: activate bit-timing calculation and netlink based
drivers by default

Marius B. Kotsbak (1):
      net/usb: kalmia: Various fixes for better support of non-x86
architectures.

Mark Brown (1):
      watchdog: Handle multiple wm831x watchdogs being registered

Maxime Bizon (1):
      serial: bcm63xx_uart: fix irq storm after rx fifo overrun.

Michael Neuling (1):
      powerpc/pseries: remove duplicate SCSI_BNX2_ISCSI in pseries_defconfig

Mike Frysinger (2):
      MAINTAINERS: mark socketcan-core lists as subscribers-only
      MAINTAINERS: drop Michael from bfin_mac driver

Márton Németh (1):
      usb: musb: host: compare status for negative error values

NeilBrown (1):
      md: avoid endless recovery loop when waiting for fail device to complete.

Nicolas Ferre (1):
      AT91: Change nand buswidth logic to match hardware default configuration

Paul Mundt (2):
      sh: Fix up unmet dependency warnings with USB EHCI/OHCI selects.
      sh: use printk_ratelimited instead of printk_ratelimit

Pavel Shved (1):
      hecubafb: add module_put on error path in hecubafb_probe()

Pawel Marek (1):
      isci: controller stop/start fixes

Petri Gynther (1):
      i2c/pca954x: Initialize the mux to disconnected state

Piotr Sawicki (11):
      isci: fix for asserts during aborts/resets to SAS/SATA in APC mode
      isci: handle cases where a d2h fis is used report an ncq error
      isci: unify request start handlers
      isci: c99 port state handlers
      isci: merge port ready substates into primary state machine
      isci: remove port start handler
      isci: unify port stop handlers
      isci: remove port destruct handler
      isci: unify port reset, add_phy, and remove_phy handlers
      isci: remove port frame and event handlers
      isci: unify port link_up and link_down handlers

Rafael J. Wysocki (1):
      PM / Runtime: Update documentation regarding driver removal

Ralf Baechle (1):
      Staging: Comedi: Build only on arches providing PAGE_KERNEL_NOCACHE

Randy Dunlap (6):
      firmware: fix GOOGLE_SMI kconfig dependency warning
      netconsole: fix build when CONFIG_NETCONSOLE_DYNAMIC is turned on
      gx1fb: Fix section mismatch warnings
      sm501fb: fix section mismatch warning
      Staging: fix more iio builds when IIO_RING_BUFFER is not enabled
      Staging: fix iio builds when IIO_RING_BUFFER is not enabled

Ron Mercer (1):
      qlge: Add maintainer.

Russ Gorby (2):
      tty: n_gsm: Fixed logic to decode break signal from modem status
      tty: n_gsm: improper skb_pull() use was leaking framed data

Sarah Sharp (5):
      xhci: Reject double add of active endpoints.
      USB: Free bandwidth when usb_disable_device is called.
      xhci: Don't warn about zeroed bMaxBurst descriptor field.
      xhci: Always set urb->status to zero for isoc endpoints.
      USB: Fix up URB error codes to reflect implementation.

Scott Wood (1):
      powerpc/e500: fix breakage with fsl_rio_mcheck_exception

Shahar Lev (1):
      drivers:misc: ti-st: fix skipping of change remote baud

Shaohui Xie (1):
      powerpc/85xx: fix NAND_CMD_READID read bytes number

Shreshtha Kumar Sahu (2):
      amba pl011: workaround for uart registers lockup
      amba pl011: platform data for reg lockup and glitch v2

Simon Horman (1):
      ARM: mach-shmobile: ag5evm: consistently name sdhi info structures

Steffen Klassert (2):
      ipv4: Fix packet size calculation in __ip_append_data
      ipv4: Fix IPsec slowpath fragmentation problem

Stephen M. Cameron (2):
      [SCSI] hpsa: fix dma unmap error in hpsa_passthru_ioctl
      [SCSI] hpsa: fix potential overrun while memcpy'ing sense data

Steven Rostedt (1):
      st_kim: Handle case of no device found for ID 0

Sven Eckelmann (1):
      MAINTAINERS: Remove Sven Eckelmann from BATMAN ADVANCED

Takashi Iwai (3):
      ALSA: cs5535 - Fix invalid big-endian conversions
      ALSA: hdspm - Fix compile warnings with PPC
      ALSA: sb16 - Fix build errors on MIPS and others with 13bit ioctl size

Timur Tabi (2):
      powerpc/p1022ds: fix audio-related properties in the device tree
      fsl-diu-fb: remove check for pixel clock ranges

Tomas Winkler (1):
      Staging: mei: fix suspend failure

Tomasz Chudy (3):
      isci: fix "no outbound task timeout" default value
      isci: Add Support for new TC completion codes
      isci: workaround port task scheduler starvation issue

Tomoya MORINAGA (1):
      8250_pci: add -ENODEV code for Intel EG20T PCH

Uwe Bonnes (1):
      USB: Add new FT232H chip to drivers/usb/serial/ftdi_sio.c

Vasiliy Kulikov (1):
      proc: restrict access to /proc/PID/io

William Katsak (1):
      udlfb: Correct sub-optimal resolution selection.

Wu Fengguang (1):
      ALSA: HDMI - fix ELD monitor name length

Xufeng Zhang (2):
      ipv6/udp: Use the correct variable to determine non-blocking condition
      udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet

Yauheni Kaliuta (1):
      usb: musb: gadget: clear TXPKTRDY flag when set FLUSHFIFO

Yinglin Luan (1):
      rionet: fix NULL pointer dereference in rionet_remove

Yoshihiro Shimoda (6):
      sh: fix compile error using sh7757lcr_defconfig
      sh: add platform_device of EHCI/OHCI to setup-sh7757
      sh: add to select the new configuration for USB EHCI/OHCI
      usb: r8a66597-hcd: fix cannot detect low/full speed device
      sh: fix the INTC vector for IRQ and IRL in setup-sh7757
      sh: fix the value of sh_dmae_slave_config in setup-sh7757

leitao@linux.vnet.ibm.com (1):
      8250: Fix capabilities when changing the port type

matt mooney (1):
      MAINTAINERS: add myself as maintainer of USB/IP

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux 3.0-rc6 ..
  2011-07-04 23:09 Linux 3.0-rc6 Linus Torvalds
@ 2011-07-06 15:27 ` Arkadiusz Miśkiewicz
  2011-07-11  6:03 ` Al Viro
  1 sibling, 0 replies; 14+ messages in thread
From: Arkadiusz Miśkiewicz @ 2011-07-06 15:27 UTC (permalink / raw)
  To: linux-kernel

Linus Torvalds wrote:

> and a happy Independence Day to all the US kernel people out there.
> 
> There is not a lot to be said about -rc6. T

Somehow uname -r still reports 3.0.0-rc6 instead of 3.0-rc6. So is this 
going to be 3.0.0 after all?

arekm


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux 3.0-rc6 ..
  2011-07-04 23:09 Linux 3.0-rc6 Linus Torvalds
  2011-07-06 15:27 ` Arkadiusz Miśkiewicz
@ 2011-07-11  6:03 ` Al Viro
  2011-07-12 23:48   ` ->d_lock FUBAR (was Re: Linux 3.0-rc6) Al Viro
  1 sibling, 1 reply; 14+ messages in thread
From: Al Viro @ 2011-07-11  6:03 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-fsdevel

On Mon, Jul 04, 2011 at 04:09:29PM -0700, Linus Torvalds wrote:

> Other than the isci driver, the rest really is just lots of random
> small stuff. It's getting to the point where I'm thinking I should
> just release 3.0, because it's been pretty quiet, and the fixes
> haven't been earth-shakingly exciting. Some drm (radeon and intel)
> fixes might be noticeable to more people, the rest would tend to be
> pretty esoteric.

Sigh...  Looks like we have serious problems around ->d_parent handling.
First of all, __d_unalias() is fscked - calling d_ancestor() is not
going to do us any good before we made sure that tree topology won't
change right under us.  Used to be protected by dcache_lock, but not
anymore.  Moreover, there's a similar problem with __d_materialise_dentry()
side of things; there we don't check for loop creation at all and with
NFS we just might try to attach a root of disconnected subtree *inside*
that subtree.  No check and no locking either...

Another piece of PITA - cifs_get_root() will cheerfully call
d_materialise_unique() on dentry it got from d_lookup() if it happens to
be negative to start with *and* directory had been created on server in
the meanwhile.  BUG_ON() triggered in d_materialise_unique()... The lack
of i_mutex on parent also doesn't help.  cifs_get_root() mess is from
this cycle, BTW.

btrfs get_default_root() doesn't grab i_mutex either.  It should, since it
calls d_splice_alias().

I'm really not fond of the code in dentry_lock_for_move(); we _might_ manage
to avoid deadlocks since i_mutex serialization might prevent contention on
d_lock, but I'm still not convinced, especially due to missing i_mutex
in several callers...  I mean, this

 * If there is an ancestor relationship:
 * dentry->d_parent->...->d_parent->d_lock
 *   ...
 *     dentry->d_parent->d_lock
 *       dentry->d_lock
 *
 * If no ancestor relationship:
 * if (dentry1 < dentry2)
 *   dentry1->d_lock
 *     dentry2->d_lock

is no good: suppose A is ancestor of B and C is unrelated to either.
With B sitting at lower address than C and A at higher one.  We have
A before B, since it's an ancestor; C before A since they are unrelated
and addresses compare that way; B before C (ditto).  Loops in lock
ordering are generally bad; we _might_ get away with that in this case
since we serialize d_move() callers to hell and back, but...

Al, going through ->d_parent code review and not happy about the state of
that animal...

^ permalink raw reply	[flat|nested] 14+ messages in thread

* ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-11  6:03 ` Al Viro
@ 2011-07-12 23:48   ` Al Viro
  2011-07-13  0:04     ` Linus Torvalds
  0 siblings, 1 reply; 14+ messages in thread
From: Al Viro @ 2011-07-12 23:48 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-fsdevel, npiggin

On Mon, Jul 11, 2011 at 07:03:15AM +0100, Al Viro wrote:

>  * If there is an ancestor relationship:
>  * dentry->d_parent->...->d_parent->d_lock
>  *   ...
>  *     dentry->d_parent->d_lock
>  *       dentry->d_lock
>  *
>  * If no ancestor relationship:
>  * if (dentry1 < dentry2)
>  *   dentry1->d_lock
>  *     dentry2->d_lock
> 
> is no good: suppose A is ancestor of B and C is unrelated to either.
> With B sitting at lower address than C and A at higher one.  We have
> A before B, since it's an ancestor; C before A since they are unrelated
> and addresses compare that way; B before C (ditto).  Loops in lock
> ordering are generally bad; we _might_ get away with that in this case
> since we serialize d_move() callers to hell and back, but...

But it's not enough.  Look: getting from rcu pathwalk to normal one
involves
	* grabbing d_lock on parent
	* grabbing d_lock on child
	* checking that child hadn't been moved elsewhere in the meanwhile
All flakiness of the locking "order" aside, here we simply lock two dentries
that might be nowhere near each other by now.  Hell, by that point the parent
might've been moved under (what used to be) child.  Or it might have address
greater than that of child and be not an ancestor anymore.  Note that no
i_mutex, etc. is held at that point, so there's no external serialization
to save our arses...

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-12 23:48   ` ->d_lock FUBAR (was Re: Linux 3.0-rc6) Al Viro
@ 2011-07-13  0:04     ` Linus Torvalds
  2011-07-13  0:56       ` Al Viro
  0 siblings, 1 reply; 14+ messages in thread
From: Linus Torvalds @ 2011-07-13  0:04 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-fsdevel, npiggin

On Tue, Jul 12, 2011 at 4:48 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> All flakiness of the locking "order" aside, here we simply lock two dentries
> that might be nowhere near each other by now.  Hell, by that point the parent
> might've been moved under (what used to be) child.  Or it might have address
> greater than that of child and be not an ancestor anymore.  Note that no
> i_mutex, etc. is held at that point, so there's no external serialization
> to save our arses...

So why wouldn't it be sufficient to just take the s_vfs_rename_mutex
in the caller? We're only talking d_materialise_unique(), no?

That said, looking at NFS (nfs_prime_dcache), we do seem to hold the
parent directory inode semaphore. So I'm not seeing any renames
happening wrt the entry we found and the parent. So the relationship
there should be safe regardless, no?

I didn't check the other users of d_materialise_unique() (ciph and
ceph) but at least the cifs use is in "readdir.c", which implies
similar directory inode mutex issues.

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-13  0:04     ` Linus Torvalds
@ 2011-07-13  0:56       ` Al Viro
  2011-07-13  1:39         ` Al Viro
  2011-07-13  1:48         ` Linus Torvalds
  0 siblings, 2 replies; 14+ messages in thread
From: Al Viro @ 2011-07-13  0:56 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-fsdevel, npiggin

On Tue, Jul 12, 2011 at 05:04:55PM -0700, Linus Torvalds wrote:

> > All flakiness of the locking "order" aside, here we simply lock two dentries
> > that might be nowhere near each other by now. ?Hell, by that point the parent
> > might've been moved under (what used to be) child. ?Or it might have address
> > greater than that of child and be not an ancestor anymore. ?Note that no
> > i_mutex, etc. is held at that point, so there's no external serialization
> > to save our arses...
> 
> So why wouldn't it be sufficient to just take the s_vfs_rename_mutex
> in the caller? We're only talking d_materialise_unique(), no?

Alas, no.  d_materialize_unique() aside (we have a couple of bugs in
there), ->d_lock handling is fscked up.  Basically, it's unlazy_walk()
taking ->d_lock instances without anything to guarantee that it's doing
that in order consistent with d_move() (and any other users, for that
matter).  *And* the "locking order" in question is not transitive, but
that's a separate story.  And no, we obviously are not going to
serialize the switch from RCU to normal pathwalk on a per-fs mutex...

I'm crawling through the d_lock users right now (>400 places ;-/), trying
to put together reasonable locking rules.

FWIW, we used to have this for d_move() et.al.:
	* all places changing ->d_parent hold i_mutex on parent(s)
	* if parents differ, we have ->s_vfs_rename_mutex as well
	* if old_dentry was not attached to the tree, it was positive
and a subdirectory of new_dentry->d_parent.  Said new_dentry->d_parent
was been locked by caller.

Unfortunately, current tree has these rules violated in several places.
And these rules have nothing to say about ->d_lock ;-/

Nick, could you please describe the locking rules you had in mind for
->d_lock?  unlazy_walk() (aka nameidata_dentry_drop_rcu()) can probably
be dealt with by checking d_seq twice, once before locking the child.
Then we could be sure that it's still a child of parent and will stay
so as long as parent's ->d_lock is held, and thus the ordering would
stay stable...

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-13  0:56       ` Al Viro
@ 2011-07-13  1:39         ` Al Viro
  2011-07-13  2:40           ` Linus Torvalds
  2011-07-13  1:48         ` Linus Torvalds
  1 sibling, 1 reply; 14+ messages in thread
From: Al Viro @ 2011-07-13  1:39 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-fsdevel, npiggin

On Wed, Jul 13, 2011 at 01:56:34AM +0100, Al Viro wrote:

> Nick, could you please describe the locking rules you had in mind for
> ->d_lock?  unlazy_walk() (aka nameidata_dentry_drop_rcu()) can probably
> be dealt with by checking d_seq twice, once before locking the child.
> Then we could be sure that it's still a child of parent and will stay
> so as long as parent's ->d_lock is held, and thus the ordering would
> stay stable...

As the matter of fact, can we ever get there with IS_ROOT(dentry)?
AFAICS, that should be impossible - dentry->d_seq would have to be
changed by whatever had torn it off the tree and we would have
buggered off on __d_rcu_to_refcount() failing...

AFAICS, the only way to get there would be with mountpoint crossing
returning a symlink with symlink already killed by rename() somehow
(call in walk_component()).  The first part should be impossible -
symlinks can't be mounted/bound on anything (and if it would be
possible, we'd trigger that BUG_ON() if symlink was still alive,
anyway).

So here's what I want to do to unlazy_walk(); it'll almost certainly
leave other problems with ->d_lock, but at least it'll take care of
that one:

Make sure that child is still a child of parent before nested locking
of child->d_lock in unlazy_walk(); otherwise we are risking a violation
of locking order and deadlocks.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/namei.c b/fs/namei.c
index 0223c41..5c867dd 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -433,6 +433,8 @@ static int unlazy_walk(struct nameidata *nd, struct dentry *dentry)
 			goto err_parent;
 		BUG_ON(nd->inode != parent->d_inode);
 	} else {
+		if (dentry->d_parent != parent)
+			goto err_parent;
 		spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED);
 		if (!__d_rcu_to_refcount(dentry, nd->seq))
 			goto err_child;

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-13  0:56       ` Al Viro
  2011-07-13  1:39         ` Al Viro
@ 2011-07-13  1:48         ` Linus Torvalds
  1 sibling, 0 replies; 14+ messages in thread
From: Linus Torvalds @ 2011-07-13  1:48 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-fsdevel, npiggin

On Tue, Jul 12, 2011 at 5:56 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Alas, no.  d_materialize_unique() aside (we have a couple of bugs in
> there), ->d_lock handling is fscked up.

Ok, I misread your previous email, and read it as if the problem you
were discussing was __d_unalias(), and then mis-read the newer email
as a result.

I now see what you're saying.

Without having thought very deeply about this, I would suggest that we
aim for entirely getting rid of anything that holds two d_lock's at
the same time. There may be cases where we do end up having both
"dentry" and the immediate parent, and in that case maybe we can have
that direct relationship act as a ordering requirement, but yes, we
should definitely aim to get rid of the whole "if ancestor do one
ordering, otherwise base it on pointer ordering".

Some of the things that take both locks make me go "do we really need
to hold those locks at the same time?" IOW, maybe the locking could be
simply sequential. Some of that pain may be simply unnecessary.

                             Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-13  1:39         ` Al Viro
@ 2011-07-13  2:40           ` Linus Torvalds
  2011-07-13  2:59             ` Al Viro
  0 siblings, 1 reply; 14+ messages in thread
From: Linus Torvalds @ 2011-07-13  2:40 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-fsdevel, npiggin

On Tue, Jul 12, 2011 at 6:39 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> So here's what I want to do to unlazy_walk(); it'll almost certainly
> leave other problems with ->d_lock, but at least it'll take care of
> that one:

That patch seems pretty clearly safe. If the parent has changed, we'd
want to exit anyway: as you point out the __d_rcu_to_refcount() is
there to catch that case. So exiting early and thus making that direct
parenthood requirement explicit in that d_lock case seems to be a good
thing regardless.

It's dentry_lock_for_move() that makes me really nervous. Not only
does it lock up to four dentries, but it mixes the whole parenthood vs
pointer ordering.  Or course, it does have those BUG_ON() checks, so
it should never cause any circular dependencies, but still..

The actual main protection to get lookups correct in the presence of
concurrent moves largely depends on the sequence numbers (ie
d_lookup() retrying if it hits a rename), which is why I also find it
unlikely that we really should need to hold all those d_lock cases all
at the same time.

So does d_move() really need to get all the locks at the same time and
then do all the operations inside that "super-locked" region? Or could
we get the locks in sequence and do individual parts of the rename
operations under individual locks?

Are there any other d_lock cases that depend on the pointer ordering?
Most everything else seems to be about direct parenthood, no?

                               Linus

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-13  2:40           ` Linus Torvalds
@ 2011-07-13  2:59             ` Al Viro
  2011-07-13  3:22               ` Al Viro
  0 siblings, 1 reply; 14+ messages in thread
From: Al Viro @ 2011-07-13  2:59 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-fsdevel, npiggin

On Tue, Jul 12, 2011 at 07:40:01PM -0700, Linus Torvalds wrote:

> It's dentry_lock_for_move() that makes me really nervous. Not only
> does it lock up to four dentries, but it mixes the whole parenthood vs
> pointer ordering.  Or course, it does have those BUG_ON() checks, so
> it should never cause any circular dependencies, but still..

Me too, obviously.

> The actual main protection to get lookups correct in the presence of
> concurrent moves largely depends on the sequence numbers (ie
> d_lookup() retrying if it hits a rename), which is why I also find it
> unlikely that we really should need to hold all those d_lock cases all
> at the same time.
> 
> So does d_move() really need to get all the locks at the same time and
> then do all the operations inside that "super-locked" region? Or could
> we get the locks in sequence and do individual parts of the rename
> operations under individual locks?
> 
> Are there any other d_lock cases that depend on the pointer ordering?
> Most everything else seems to be about direct parenthood, no?

It's not that easy.  We want ->d_lock on parents - not only because
there's code iterating through the list of children, but because
ordering on direct parenthood bloody depends on children not moving
out while we hold ->d_lock on their parent.  Otherwise we are looking
for nightmares in shrink_dcache_parent() et.al.

I'm not sure how much do we care about stability of x->d_parent when
x->d_lock is held.  ->d_compare() is the most obvious potential area
of trouble in that respect, but there might be more.

I'm still not finished reviewing ->d_lock uses; about a couple of hundreds
is left to wade through.  I would really, *REALLY* appreciate explicitly
defined locking rules from Nick (it's his changes, mostly).  As in "this,
this and that field is protected by ->d_lock on..."

Note that ->d_parent is stable when i_mutex is held on parent, which
makes most of the users of ->d_parent safe and fine (->lookup(), etc.
are all called with directory locked).  I've not finished reviewing
->d_parent users either, but IMO ->d_lock review is more important, so
it got bumped in front of queue...

Back to GrepTFS and stripping the paint off the walls...

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-13  2:59             ` Al Viro
@ 2011-07-13  3:22               ` Al Viro
  2011-07-13  3:56                 ` Linus Torvalds
  0 siblings, 1 reply; 14+ messages in thread
From: Al Viro @ 2011-07-13  3:22 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-fsdevel, npiggin

On Wed, Jul 13, 2011 at 03:59:18AM +0100, Al Viro wrote:

> I'm not sure how much do we care about stability of x->d_parent when
> x->d_lock is held.  ->d_compare() is the most obvious potential area
> of trouble in that respect, but there might be more.

Oh, and another fun area is per-chain locks, of course ;-/  Look at
__d_drop(); reengineering the callers of d_drop() to make sure that
fscker's parent stays stable would be very painful and turning that
into loop-based variant is going to be interesting.  Doable, but not
fun...

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-13  3:22               ` Al Viro
@ 2011-07-13  3:56                 ` Linus Torvalds
  2011-07-14  7:21                   ` Al Viro
  0 siblings, 1 reply; 14+ messages in thread
From: Linus Torvalds @ 2011-07-13  3:56 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-fsdevel, npiggin

On Tue, Jul 12, 2011 at 8:22 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Oh, and another fun area is per-chain locks, of course ;-/  Look at
> __d_drop(); reengineering the callers of d_drop() to make sure that
> fscker's parent stays stable would be very painful and turning that
> into loop-based variant is going to be interesting.  Doable, but not
> fun...

So I'm almost convinced.

The reason I say "almost" is that I wonder if we couldn't just turn
the d_move() into basically a

   write_seqlock(rename_lock);
   write_seqcount_begin(dentry);
   write_seqcount_begin(target);

   unhash(dentry);  /* Takes and releases dentry/dentry-parent locks */
   unhash(target);  /* Takes and releases target/target-parent locks */

   tname = target->name;
   dname = dentry->name;

   rehash(dentry, tname); /* takes/releases locks as above.. */
   rehash(target, dname); /* takes/releases locks as above.. */

   write_seqcount_end(target);
   write_seqcount_end(dentry);
   write_sequnlock(rename_lock);

where the seqlock and sequence counts mean that any lookups (RCU or
not) while the thing was unhashed get automatically re-done, so the
fact that it's not at "atomic" move in between would not important.

See what I'm saying? Sure, we want to hold both the dentry and parent
locks when messing with dentry->d_parent: but does that really mean
that we want to hold all FOUR locks at the same time, and in
particular hold those *independent* locks (which is why we do that
pointer value comparison, to give ordering *outside* of the parenthood
issue)?

IOW, maybe we could just hold and release them pairwise, and at any
one point in time we'd only hold one pair of dentry/parent d_lock? No
dentry-pointer-based ordering required - but we'd still protect each
d_parent pointer _individually_.

But I didn't really look closely at the code. The above suggestion is
purely based on my high-level gut feel, and it's entirely possible
that there's some particular practical reason why it's a totally
broken idea, and I'm just a complete moron. I'm realizing, for
example, that maybe we can't even do the dentry seqcount without
holding d_lock?

It would take the locks a few more times, but it would avoid the nasty
lock ordering issues exactly because it drops them in between rather
than try to hold them all at once. And d_move() is *not* a performance
critical area, afaik, so the point would be to make the locking more
straightforward and avoid the horrible subtlety.

Crazy? Stupid? What am I missing? It's probably something obvious.

                            Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-13  3:56                 ` Linus Torvalds
@ 2011-07-14  7:21                   ` Al Viro
  2011-07-15  4:58                     ` Al Viro
  0 siblings, 1 reply; 14+ messages in thread
From: Al Viro @ 2011-07-14  7:21 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-fsdevel, npiggin

On Tue, Jul 12, 2011 at 08:56:35PM -0700, Linus Torvalds wrote:

> It would take the locks a few more times, but it would avoid the nasty
> lock ordering issues exactly because it drops them in between rather
> than try to hold them all at once. And d_move() is *not* a performance
> critical area, afaik, so the point would be to make the locking more
> straightforward and avoid the horrible subtlety.
> 
> Crazy? Stupid? What am I missing? It's probably something obvious.

	It's loops over d_subdirs of given dentry.  IOW, dentry can
be found not just via the hash chains and those iterators (ones outside
of fs/dcache.c) don't play with rename seqlock.  They just rely on ->d_lock
on dentry being enough to stabilize the list of children.

It's not all that horrible, since i_mutex on parent (held in quite a
few of those) is enough to prevent d_move() altogether.  Or iterator
sits on fs that never does d_move/d_materialise_unique at all.  There
are exceptions. The most generic one is __fsnotify_update_child_dentry_flags(),
but that's not all.  E.g. coda ->d_revalidate(), possibly some ceph code...
Overall, it might be doable, but it'll take some massage in strange places.
Hell knows; I think at that point in release cycle we don't want to go
there.  After looking through ->d_lock users I'm mostly convinced that
unlazy_walk() fix + making damn sure we don't try to create loops in
d_materialise_unique() + adding missing ->i_mutex where needed is the
way to go for now.  We have several places where ->d_lock overlap is
not parent-to-child, but these really can't lead to deadlocks - fs is
specialized enough to prevent them.

However, looking through these loops over ->d_subdirs shows *another* pile of
bugs, like this one:
        mutex_lock(&bus->d_inode->i_mutex);

        list_for_each_entry(dev, &bus->d_subdirs, d_u.d_child)
                if (dev->d_inode)
                        update_dev(dev);

        mutex_unlock(&bus->d_inode->i_mutex);
in drivers/usb/core/inode.c:update_bus().  See the problem?  Sure,
it's ramfs-like: all dentries are pinned down until unlink/rmdir,
which is blocked by i_mutex on parent.  And yes, d_move() is also
not a problem (ditto).  However, if you open a file and unlink it,
dentry will be unpinned, but stay around.  It will be unhashed,
but it'll be on ->d_subdir.  Close the file and dentry will be killed,
without i_mutex on parent.  Note that ->d_locked will be taken -
both on victim and parent.  But the quoted sucker takes no ->d_lock
at all.  Bummer...

IOW, iterators relying _purely_ on i_mutex on parent are currently fucked.
We have more such cases.  Another one is debugfs_remove_recursive().

I wonder if we simply ought to evict the sucker from d_subdirs/d_child
in simple_unlink()...  It would require verifying that users of that
animal are OK with that, but I suspect that most of them will be happy.
It might simplify life for readdir() and llseek() on such directories,
while we are at it...  The "hunt for dentry leaks" logics on umount
might become slightly less useful for those filesystems (we'll get
"parent is misteriously busy" instead of "child is unlinked, but somehow
busy on fs shutdown"), but I doubt it's that serious.  Hell knows -
I never had to hunt dentry leaks on debugfs/usbfs/etc.

BTW, usbfs tree iterators should've been killed a long time ago - we
simply need ->permission() and ->getattr() added for usbfs to DTRT
instead of this "iterate over all inodes, patch new i_uid/i_gid/i_mode
when remount asks to do that" crap.

BTW^2: in clk_debugfs_register_one() in assorted arch/arm/mach-*/clock.c
        d = c->dent;
        list_for_each_entry_safe(child, child_tmp, &d->d_subdirs, d_u.d_child)
                debugfs_remove(child);
        debugfs_remove(c->dent);
should be debugfs_remove_recursive().  Here we don't even bother with
i_mutex...

BTW^3: sel_remove_classes() plays very unsafe games - no ->i_mutex at all, no
->d_lock until we get leaf directories.  Root-only, but...

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6)
  2011-07-14  7:21                   ` Al Viro
@ 2011-07-15  4:58                     ` Al Viro
  0 siblings, 0 replies; 14+ messages in thread
From: Al Viro @ 2011-07-15  4:58 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-fsdevel, npiggin

On Thu, Jul 14, 2011 at 08:21:20AM +0100, Al Viro wrote:
> Overall, it might be doable, but it'll take some massage in strange places.
> Hell knows; I think at that point in release cycle we don't want to go
> there.  After looking through ->d_lock users I'm mostly convinced that
> unlazy_walk() fix + making damn sure we don't try to create loops in
> d_materialise_unique() + adding missing ->i_mutex where needed is the
> way to go for now.  We have several places where ->d_lock overlap is
> not parent-to-child, but these really can't lead to deadlocks - fs is
> specialized enough to prevent them.

OK, hopefully that should take care of the ->d_lock for now; missing
->i_mutex is *not* dealt with yet, since I'm yet to finish ->d_parent
code review.  dentry_lock_for_move() is serialized by rename_lock now
(call in __dentry_materialise_unique() used to be done without it; fixed
in this series), so we can't have more than one of those in any potential
deadlock set.  Everything else either does lock child after immediate
parent or happens on filesystems that see neither d_move() nor
d_materialise_unique() and have serialization of their own.  IOW, I
think that should be enough to avoid deadlocks for in-tree filesystems
for the time being; anything more dramatic will have to wait for the
next merge window - it's too late in the cycle to do anything daring
in that area...  Usual place,

git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ for-linus

Shortlog:
Al Viro (2):
      Fix ->d_lock locking order in unlazy_walk()
      fix loop checks in d_materialise_unique()

Diffstat:
 fs/dcache.c |   51 ++++++++++++++++++++++++++++++++++-----------------
 fs/namei.c  |    2 ++
 2 files changed, 36 insertions(+), 17 deletions(-)

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2011-07-15  4:59 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-04 23:09 Linux 3.0-rc6 Linus Torvalds
2011-07-06 15:27 ` Arkadiusz Miśkiewicz
2011-07-11  6:03 ` Al Viro
2011-07-12 23:48   ` ->d_lock FUBAR (was Re: Linux 3.0-rc6) Al Viro
2011-07-13  0:04     ` Linus Torvalds
2011-07-13  0:56       ` Al Viro
2011-07-13  1:39         ` Al Viro
2011-07-13  2:40           ` Linus Torvalds
2011-07-13  2:59             ` Al Viro
2011-07-13  3:22               ` Al Viro
2011-07-13  3:56                 ` Linus Torvalds
2011-07-14  7:21                   ` Al Viro
2011-07-15  4:58                     ` Al Viro
2011-07-13  1:48         ` Linus Torvalds

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.