On Tue, Nov 28, 2023 at 10:04:02PM +0000, Nick Terrell wrote: > Hi Kent, > > I see in the bcachefs compression code this comment [0]: > > Additionally, the ZSTD code seems to have a bug where it will > write just past the end of the buffer - so subtract a fudge > factor (7 bytes) from the dst buffer size to account for > that. > > This is very unexpected, as zstd is extensively fuzzed for these types of > bugs. > It doesn’t look like bcachefs is using zstd in a way that would trigger a > unique > code path, so my first suspicion is that there is a bug in the way that > bcachefs > is calling zstd. > > I spent some time trying to reproduce the issue by calling zstd in the same > way > that bcachefs called zstd when the workaround was landed, but so far haven’t > been successful in triggering the bug. > > If you can provide a reproducer, I will look into the issue further. If you > can > provide the input data, the size of the output buffer used, and the parameters > used (or the level & estimated source size used to derive the parameters), I > will definitely be able to debug the issue, and get it fixed if it is a > problem with > zstd.
Which bug? the write past end of buffer, or the -ENOMEM?
