On Wed, Sep 25, 2019 at 07:53:53AM +1000, Dave Chinner wrote: > On Tue, Sep 24, 2019 at 11:19:29PM +0200, Vlastimil Babka wrote: > > On 9/23/19 7:51 PM, Darrick J. Wong wrote: > > > On Mon, Sep 23, 2019 at 07:17:10PM +0200, David Sterba wrote: > > >> On Mon, Sep 23, 2019 at 06:36:32PM +0200, Vlastimil Babka wrote: > > >>> So if anyone thinks this is a good idea, please express it (preferably > > >>> in a formal way such as Acked-by), otherwise it seems the patch will be > > >>> dropped (due to a private NACK, apparently). > > > > > > Oh, I didn't realize ^^^^^^^^^^^^ that *some* of us are allowed the > > > privilege of gutting a patch via private NAK without any of that open > > > development discussion incovenience. <grumble> > > > > > > As far as XFS is concerned I merged Dave's series that checks the > > > alignment of io memory allocations and falls back to vmalloc if the > > > alignment won't work, because I got tired of scrolling past the endless > > > discussion and bug reports and inaction spanning months. > > > > I think it's a big fail of kmalloc API that you have to do that, and > > especially with vmalloc, which has the overhead of setting up page > > tables, and it's a waste for allocation requests smaller than page size. > > I wish we could have nice things. > > I don't think the problem here is the code. The problem here is that > we have a dysfunctional development community and there are no > processes we can follow to ensure architectural problems in core > subsystems are addressed in a timely manner... > > And this criticism isn't just of the mm/ here - this alignment > problem is exacerbated by exactly the same issue on the block layer > side. i.e. the block layer and drivers have -zero- bounds checking > to catch these sorts of things and the block layer maintainer will > not accept patches for runtime checks that would catch these issues > and make them instantly visible to us. > > These are not code problems: we can fix the problems with code (and > I have done so to demonstrate "this is how we do what you say is > impossible"). The problem here is people in positions of > control/power are repeatedly demonstrating an inability to > compromise to reach a solution that works for everyone. > > It's far better for us just to work around bullshit like this in XFS > now, then when the core subsystems get they act together years down > the track we can remove the workaround from XFS. Users don't care > how we fix the problem, they just want it fixed. If that means we > have to route around dysfunctional developer groups, then we'll just > have to do that.... Seconded. --D > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
