Hi all,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/md/bcache/btree.c: In function 'bch_btree_check':
drivers/md/bcache/btree.c:2073:1: error: the frame size of 2184 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
2073 | }
| ^
Caused by commit
c766acd3d78e ("bcache: improve multithreaded bch_btree_check()")
struct btree_check_state is very large to put on the stack :-(
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
On 5/22/22 8:49 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/md/bcache/btree.c: In function 'bch_btree_check':
> drivers/md/bcache/btree.c:2073:1: error: the frame size of 2184 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> 2073 | }
> | ^
>
> Caused by commit
>
> c766acd3d78e ("bcache: improve multithreaded bch_btree_check()")
>
> struct btree_check_state is very large to put on the stack :-(
>
> I have reverted that commit for today.
Thanks, I'll drop it. It's not part of the initial request sent to
Linus, exactly because it arrived late.
Coly, I'm dropping this series.
--
Jens Axboe
On 5/23/22 10:52 AM, Jens Axboe wrote:
> On 5/22/22 8:49 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/md/bcache/btree.c: In function 'bch_btree_check':
>> drivers/md/bcache/btree.c:2073:1: error: the frame size of 2184 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>> 2073 | }
>> | ^
>>
>> Caused by commit
>>
>> c766acd3d78e ("bcache: improve multithreaded bch_btree_check()")
>>
>> struct btree_check_state is very large to put on the stack :-(
>>
>> I have reverted that commit for today.
Hi Jens,
> Thanks, I'll drop it. It's not part of the initial request sent to
> Linus, exactly because it arrived late.
>
> Coly, I'm dropping this series.
Yes please. Should I re-submit the fixed series to you in later -RC
round, or wait for 5.20 merge window?
Thanks.
Coly Li
On 5/23/22 12:05 AM, Coly Li wrote:
> On 5/23/22 10:52 AM, Jens Axboe wrote:
>> On 5/22/22 8:49 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> After merging the block tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> drivers/md/bcache/btree.c: In function 'bch_btree_check':
>>> drivers/md/bcache/btree.c:2073:1: error: the frame size of 2184 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>>> 2073 | }
>>> | ^
>>>
>>> Caused by commit
>>>
>>> c766acd3d78e ("bcache: improve multithreaded bch_btree_check()")
>>>
>>> struct btree_check_state is very large to put on the stack :-(
>>>
>>> I have reverted that commit for today.
>
> Hi Jens,
>
>> Thanks, I'll drop it. It's not part of the initial request sent to
>> Linus, exactly because it arrived late.
>>
>> Coly, I'm dropping this series.
>
> Yes please. Should I re-submit the fixed series to you in later -RC
> round, or wait for 5.20 merge window?
Just resubmit it when it's been fixed, then we'll figure it out at that
point. As mentioned in the original email, at the very least it needs a
linux-next soak for a weeks time. If the patches are simple enough and
don't cause odd build errors/warnings, then we can still make this
release if need be.
--
Jens Axboe
On Fri, Jul 15, 2022 at 02:02:59PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/block/ublk_drv.c:951:19: error: 'no_llseek' undeclared here (not in a function); did you mean 'noop_llseek'?
> 951 | .llseek = no_llseek,
> | ^~~~~~~~~
> | noop_llseek
>
> Caused by commit
>
> 71f28f3136af ("ublk_drv: add io_uring based userspace block driver")
>
> interacting with commit
>
> 8804bffa93a1 ("fs: remove no_llseek")
>
> from the vfs tree.
I suspect that it would be a good idea to slap
#define no_llseek NULL
into include/linux/fs.h for the merge window, then remove it (and all
stray no_llseek initializers) at -rc1. Linus, would you be OK with
that approach?
On 7/14/22 10:10 PM, Al Viro wrote:
> On Fri, Jul 15, 2022 at 02:02:59PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/block/ublk_drv.c:951:19: error: 'no_llseek' undeclared here (not in a function); did you mean 'noop_llseek'?
>> 951 | .llseek = no_llseek,
>> | ^~~~~~~~~
>> | noop_llseek
>>
>> Caused by commit
>>
>> 71f28f3136af ("ublk_drv: add io_uring based userspace block driver")
>>
>> interacting with commit
>>
>> 8804bffa93a1 ("fs: remove no_llseek")
>>
>> from the vfs tree.
>
> I suspect that it would be a good idea to slap
> #define no_llseek NULL
> into include/linux/fs.h for the merge window, then remove it (and all
> stray no_llseek initializers) at -rc1. Linus, would you be OK with
> that approach?
Not Linus, but I think that's a good idea as it'll reduce the pain for
any new users added in other trees.
--
Jens Axboe
On Fri, Jul 15, 2022 at 7:43 AM Jens Axboe <[email protected]> wrote:
>
> On 7/14/22 10:10 PM, Al Viro wrote:
> >
> > I suspect that it would be a good idea to slap
> > #define no_llseek NULL
> > into include/linux/fs.h for the merge window, then remove it (and all
> > stray no_llseek initializers) at -rc1. Linus, would you be OK with
> > that approach?
>
> Not Linus, but I think that's a good idea as it'll reduce the pain for
> any new users added in other trees.
Yeah, sounds fine to me too.
Linus
On Fri, Jul 15, 2022 at 10:33:30AM -0700, Linus Torvalds wrote:
> On Fri, Jul 15, 2022 at 7:43 AM Jens Axboe <[email protected]> wrote:
> >
> > On 7/14/22 10:10 PM, Al Viro wrote:
> > >
> > > I suspect that it would be a good idea to slap
> > > #define no_llseek NULL
> > > into include/linux/fs.h for the merge window, then remove it (and all
> > > stray no_llseek initializers) at -rc1. Linus, would you be OK with
> > > that approach?
> >
> > Not Linus, but I think that's a good idea as it'll reduce the pain for
> > any new users added in other trees.
>
> Yeah, sounds fine to me too.
OK, branch rearranged (#work.lseek-2 now), along with #for-next.
After that we have no_llseek defined to NULL and all its instances
consisting of
1) that define
2) a bunch of initializers of .llseek
3) one mentioning in Documentation/filesystems/porting.rst
So if you could run
git grep -l -w no_llseek | grep -v porting.rst | while read i; do
sed -i '/\<no_llseek\>/d' $i
done
just before -rc1, it would deal with the problem with minimal
conflicts during the merge window.
FWIW, right now diffstat of that branch is
Documentation/filesystems/porting.rst | 8 ++++++++
drivers/dma-buf/dma-buf.c | 1 -
drivers/gpu/drm/drm_file.c | 3 +--
drivers/vfio/vfio.c | 2 +-
fs/coredump.c | 4 ++--
fs/file_table.c | 2 ++
fs/open.c | 2 ++
fs/overlayfs/copy_up.c | 3 +--
fs/read_write.c | 17 +++--------------
fs/splice.c | 10 ++++------
include/linux/fs.h | 2 +-
kernel/bpf/bpf_iter.c | 3 +--
12 files changed, 26 insertions(+), 31 deletions(-)
without any changes in file_operations initializers. With 270-odd
more lines removed by the loop above...