* 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.