Re: [PATCH 1/1] Revert "iomap: fall back to buffered writes for invalidation failures"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 09, 2022 at 03:59:48PM +0000, Lee Jones wrote:
> On Wed, 09 Feb 2022, Christoph Hellwig wrote:
> 
> > On Wed, Feb 09, 2022 at 08:52:43AM +0000, Lee Jones wrote:
> > > This reverts commit 60263d5889e6dc5987dc51b801be4955ff2e4aa7.
> > > 
> > > Reverting since this commit opens a potential avenue for abuse.
> > > 
> > > The C-reproducer and more information can be found at the link below.
> > > 
> > > With this patch applied, I can no longer get the repro to trigger.
> > 
> > Well, maybe you should actually debug and try to understand what is
> > going on before blindly reverting random commits.
> 
> That is not a reasonable suggestion.
> 
> Requesting that someone becomes an area expert on a huge and complex
> subject such as file systems (various) in order to fix your broken
> code is not rational.

Sending a patch to revert a change you don't understand is also
not rational.  If you've bisected it to a single change -- great!
If reverting the patch still fixes the bug -- also great!  But
don't send a patch when you clearly don't understand what the
patch did.

> If you'd like to use the PoC provided as a basis to test your own
> solution, then go right ahead.  However, as it stands this API should
> be considered to contain security risk and should be patched as
> quickly as can be mustered.  Reversion of the offending commit seems
> to be the fastest method to achieve that currently.

This is incoherent.  There is no security risk.



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux