Re: [PATCH v4 10/10] scsi: scsi_debug: Validate the access parameters of WRITE ATOMIC (16)

[Niklas Cassel <cassel@kernel.org>]

On Fri, Sep 18, 2026 at 09:19:30AM +0100, John Garry wrote:
> On 9/18/26 08:53, Niklas Cassel wrote:
> > > > Call check_device_access_params(). The zone checks that it ends with are
> > > > unreachable, as atomic writes and ZBC emulation are mutually exclusive.
> > > These are quite verbose commit messages ... LLM-generated, by chance?
> > Yes, hence the Assisted-by tag just a few lines further down:
> 
> I didn't know which part was :)
> 
> > 
> > > > Assisted-by: LLM
> > > > Fixes: 84f3a3c01d70 ("scsi: scsi_debug: Atomic write support")
> > > > Signed-off-by: Niklas Cassel<cassel@kernel.org>
> > The commit message does point out two actual problems resulting from the
> > missing check_device_access_params() call in resp_atomic_write() (which
> > exists in all other resp_write_*() functions):
> > 
> > - Fails to repect the write protect module parameter, so resp_atomic_write()
> >    fails to generate the proper sense data in this case.
> > 
> > - Fails to check if the command will write past that device capacity, so
> >    resp_atomic_write() fails to generate the proper sense data in this case.
> > 
> > The generated sense data differs in the two cases.
> > 
> > I suppose we could drop:
> > 
> >    As a consequence a WRITE ATOMIC (16) past the end of the device is not
> >    terminated with LOGICAL BLOCK ADDRESS OUT OF RANGE. do_device_access()
> >    reduces the LBA modulo the size of the store, so the command writes
> >    somewhere else on the medium instead. A WRITE ATOMIC (16) also writes to
> >    a device whose wp module parameter is set, which every other write
> >    refuses with DATA PROTECT.
> > 
> > 
> >  From the commit message, as I suppose it might be a bit overly verbose to
> > mention the exact sense data that each missing check would generate.
> > If someone cares about that, they can just look at the mk_sense_buffer()
> > calls in check_device_access_params().
> 
> I don't really care too much. I personally just find these LLM-generated
> commit messages laborious to read.

I do also often find LLM-generated commit messages very verbose.

But at the same time, I often find commit messages written by (most) humans
way too sparse.

Linus himself is a big fan of very verbose commit messages:
https://lore.kernel.org/all/20150314075357.GA8319@gmail.com/

But of course, there is a difference between very verbose commit messages
written by a human, and very verbose commit messages written by an LLM.

I doubt that LLM-generated commit messages are going away (and for non-native
speakers, I very much think that they are an improvement to what we were used
to), but as AI models get better and better, hopefully, they will eventually
learn how to write more concise commit messages by default.

I can imagine that it is already possible with an AI kernel skill.md that
instructs the agent to write commit messages more concise than their default.


Kind regards,
Niklas