Hello, Dave.
On Fri, Dec 20, 2013 at 11:51:14AM +1100, Dave Chinner wrote:
> > Please note that there's no real "immediacy" in that it's inherently
> > racy and that the extent of the usefulness of such notification can't
> > reach much further than suppressing error messages.
>
> So says you. Wh
On Thursday, December 19, 2013 11:24:11 AM Tejun Heo wrote:
> Yo, Dave.
>
> On Thu, Dec 19, 2013 at 03:08:21PM +1100, Dave Chinner wrote:
> > > If knowing that the underlying device has gone away somehow helps
> > > filesystem, maybe we can expose that interface and avoid flushing
> > > after hotu
On Thu, Dec 19, 2013 at 11:24:11AM -0500, Tejun Heo wrote:
> Yo, Dave.
>
> On Thu, Dec 19, 2013 at 03:08:21PM +1100, Dave Chinner wrote:
> > > If knowing that the underlying device has gone away somehow helps
> > > filesystem, maybe we can expose that interface and avoid flushing
> > > after hotun
Yo, Dave.
On Thu, Dec 19, 2013 at 03:08:21PM +1100, Dave Chinner wrote:
> > If knowing that the underlying device has gone away somehow helps
> > filesystem, maybe we can expose that interface and avoid flushing
> > after hotunplug but that merely hides the possible deadlock scenario
> > that you'
On Wed, Dec 18, 2013 at 06:43:43AM -0500, Tejun Heo wrote:
> Hello, Dave.
>
> On Wed, Dec 18, 2013 at 11:35:10AM +1100, Dave Chinner wrote:
> > Perhaps the function "invalidate_partition()" is badly named. To
> > state the obvious, fsync != invalidation. What it does is:
> >
> > 1. sync files
On Wednesday, December 18, 2013 06:43:43 AM Tejun Heo wrote:
[...]
> If filesystems need an indication that the underlying device is no
> longer functional, please go ahead and add it, but please keep in mind
> all these are completely asynchronous. Nothing guarantees you that
> such events woul
Hello, Dave.
On Wed, Dec 18, 2013 at 11:35:10AM +1100, Dave Chinner wrote:
> Sure I understand the problem. Part of that dependency loop is
> caused by filesystem re-entrancy from the hot unplug code.
> Regardless of this /specific freezer problem/, that filesystem
> re-entrancy path is *never OK*
On Mon, Dec 16, 2013 at 07:56:04AM -0500, Tejun Heo wrote:
> On Mon, Dec 16, 2013 at 07:51:24AM -0500, Tejun Heo wrote:
> > On Mon, Dec 16, 2013 at 02:56:52PM +1100, Dave Chinner wrote:
> > > > What are you suggesting? Implementing separate warm and hot unplug
> > > > paths? That makes no sense w
On Mon, Dec 16, 2013 at 07:51:24AM -0500, Tejun Heo wrote:
> On Mon, Dec 16, 2013 at 02:56:52PM +1100, Dave Chinner wrote:
> > > What are you suggesting? Implementing separate warm and hot unplug
> > > paths? That makes no sense whatsoever. Device hot unplug is just a
> > > sub operation of gene
On Mon, Dec 16, 2013 at 02:56:52PM +1100, Dave Chinner wrote:
> > What are you suggesting? Implementing separate warm and hot unplug
> > paths? That makes no sense whatsoever. Device hot unplug is just a
> > sub operation of general device unplug which should be able to succeed
> > whether the u
On Sat, Dec 14, 2013 at 03:23:24PM -0500, Tejun Heo wrote:
> Hello, Dave.
>
> On Sat, Dec 14, 2013 at 12:53:43PM +1100, Dave Chinner wrote:
> > That's the fundamental problem here - device removal asks the device
> > to fsync the filesystem on top of the device that was just removed.
> > The simpl
Hello, Dave.
On Sat, Dec 14, 2013 at 12:53:43PM +1100, Dave Chinner wrote:
> That's the fundamental problem here - device removal asks the device
> to fsync the filesystem on top of the device that was just removed.
> The simple way to trigger this is to pull a device from underneath
> an active f
On Sat, Dec 14, 2013 at 12:53:43PM +1100, Dave Chinner wrote:
> > Ideas?
>
> Fix the device delete error handling not to re-enter the
> filesystem and IO path. It's just wrong.
That sounds totally reasonable to me, what is preventing someone from
making this change?
thanks,
greg k-h
--
To unsub
On Fri, Dec 13, 2013 at 12:49:32PM -0500, Tejun Heo wrote:
> Hello, guys.
>
> This is discovered while investigating bug 62801 - "EliteBoot hangs at
> dock, suspend, undock, resume".
>
> https://bugzilla.kernel.org/show_bug.cgi?id=62801
>
> The laptop locks up during resume if undocked while su
On Fri, Dec 13, 2013 at 12:49:32PM -0500, Tejun Heo wrote:
> I'm not completely sure what to do. We can make an exception for
> bdi_wq and thaw it early but that breaks the guarantee that bdi is
> frozen between device suspend and resume invocations and we might as
> well just remove WQ_FREEZABLE
15 matches
Mail list logo