The first half of the 4.19 merge window

FWIW, from Documentation/filesystems/porting:
[mandatory]
->atomic_open() calling conventions have changed. Gone is int *opened,
along with FILE_OPENED/FILE_CREATED. In place of those we have
FMODE_OPENED/FMODE_CREATED, set in file->f_mode. Additionally, return
value for 'called finish_no_open(), open it yourself' case has become
0, not 1. Since finish_no_open() itself is returning 0 now, that part
does not need any changes in ->atomic_open() instances.

That one affects all filesystems providing ->atomic_open(). And this
[mandatory]
alloc_file() has become static now; two wrappers are to be used instead.
alloc_file_pseudo(inode, vfsmount, name, flags, ops) is for the cases
when dentry needs to be created; that's the majority of old alloc_file()
users. Calling conventions: on success a reference to new struct file
is returned and callers reference to inode is subsumed by that. On
failure, ERR_PTR() is returned and no caller's references are affected,
so the caller needs to drop the inode reference it held.
alloc_file_clone(file, flags, ops) does not affect any caller's references.
On success you get a new struct file sharing the mount/dentry with the
original, on failure - ERR_PTR().

affects the drivers playing with alloc_file() - much fewer of those in there, but also an incompatible API change.

That, BTW, is a nice example of the reasons why there isn't and there won't be any promises of in-kernel interface stability - if a change makes sense (e.g. makes for much simpler cleanup logics on failure exits), it is done, period.

PS: generally, that file is worth watching when looking for infrastructure changes...