Page MenuHomePhabricator

[C2x] reject type definitions in offsetof
AcceptedPublic

Authored by inclyc on Sep 9 2022, 6:09 AM.

Details

Reviewers
aaron.ballman
shafik
nickdesaulniers
nathanchance
Group Reviewers
Restricted Project
Summary

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof. After
this patch clang will reject any type definitions in __builtin_offsetof.

Fixes https://github.com/llvm/llvm-project/issues/57065

local/offsetof.c:10:38: error: 'struct S' cannot be defined in '__builtin_offsetof'
    return __builtin_offsetof(struct S{ int a, b;}, a);
                                     ^

Diff Detail

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
inclyc published this revision for review.Sep 9 2022, 6:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 9 2022, 6:16 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
inclyc edited the summary of this revision. (Show Details)Sep 9 2022, 6:20 AM
inclyc updated this revision to Diff 459037.Sep 9 2022, 6:25 AM

Add release notes

inclyc updated this revision to Diff 459039.Sep 9 2022, 6:27 AM

Use double backquotes

Thank you for working on this! This approach can work (though I would recommend using an RAII object akin to InMessageExpressionRAIIObject), but have you explored making a new DeclSpecContext and modifying isDefiningTypeSpecifierContext()? I think that would likely be a cleaner approach.

inclyc planned changes to this revision.Sep 9 2022, 1:07 PM
inclyc updated this revision to Diff 459248.Sep 9 2022, 9:11 PM

Use RAII object to maintain the Parser state

have you explored making a new DeclSpecContext and modifying isDefiningTypeSpecifierContext()? I think that would likely be a cleaner approach.

Emm, I've tried passing a DeclaratorContext into ParseTypeName()

SourceLocation TypeLoc = Tok.getLocation();
InBuiltInOffsetOfBaseRAIIObject InOffsetof(*this, true);
TypeResult Ty = ParseTypeName(nullptr, /*Context=???*/);

But defining a new DeclaratorContext I have to complete a bunch of case
statements.

// Parser.h
static bool isTypeSpecifier(DeclSpecContext DSC);
static AllowDefiningTypeSpec isDefiningTypeSpecifierContext(DeclSpecContext DSC, bool IsCPlusPlus);
static bool isOpaqueEnumDeclarationContext(DeclSpecContext DSC);
/* ... */

And I think it is somehow strange to determine these properties within
__builtin_offsetof()? I'm not sure if it is really appropriate to define a
special context for a built-in function. This place should only need to
forbidden definitions, right?

Use RAII object to maintain the Parser state

have you explored making a new DeclSpecContext and modifying isDefiningTypeSpecifierContext()? I think that would likely be a cleaner approach.

Emm, I've tried passing a DeclaratorContext into ParseTypeName()

SourceLocation TypeLoc = Tok.getLocation();
InBuiltInOffsetOfBaseRAIIObject InOffsetof(*this, true);
TypeResult Ty = ParseTypeName(nullptr, /*Context=???*/);

But defining a new DeclaratorContext I have to complete a bunch of case
statements.

// Parser.h
static bool isTypeSpecifier(DeclSpecContext DSC);
static AllowDefiningTypeSpec isDefiningTypeSpecifierContext(DeclSpecContext DSC, bool IsCPlusPlus);
static bool isOpaqueEnumDeclarationContext(DeclSpecContext DSC);
/* ... */

And I think it is somehow strange to determine these properties within
__builtin_offsetof()? I'm not sure if it is really appropriate to define a
special context for a built-in function. This place should only need to
forbidden definitions, right?

The thing is: it really is a declaration context; one in which type declarations are not allowed. So yes, you do have to fill out a bunch of fully covered switches in places, but I still think that's the correct way to model this instead of introducing a one-off RAII object.

inclyc updated this revision to Diff 459458.Sep 12 2022, 7:42 AM

Use declaration context

shafik added a subscriber: shafik.Sep 12 2022, 1:18 PM
shafik added inline comments.
clang/include/clang/Parse/Parser.h
2287

Why true for this case? What does this allow that we want? Do we test it?

clang/lib/Parse/ParseExpr.cpp
2583
inclyc updated this revision to Diff 459633.Sep 12 2022, 7:52 PM

Address comments

inclyc updated this revision to Diff 459634.Sep 12 2022, 8:02 PM

git-clang-format

aaron.ballman added inline comments.Sep 14 2022, 9:57 AM
clang/include/clang/Parse/Parser.h
2313

Is this correct? I don't think we can deduce the type from offsetof through CTAD, can we?

https://godbolt.org/z/Kab6ahYe7

(This might be a good test case to add assuming we don't already have that coverage.)

clang/include/clang/Sema/DeclSpec.h
2069 ↗(On Diff #459634)

I don't think we can omit the identifier in this context -- this function is used to see whether you can do something like:

template <int>
void func(int) {
  try {
  } catch (int) {
  }
}

and offsetof seems quite different from that.

clang/test/Sema/offsetof.c
79 ↗(On Diff #459634)

I think this is defensible. The wording in the standard is "If the specified type defines a new type or if the specified member is a bit-field, the behavior is undefined." and the specified type in this case is struct A; that struct A happens to also define struct B is immaterial.

However, the intent behind the change to the rule is to support older implementations of offsetof to protect them from having to deal with a case like: offsetof(struct S { int a, b }, b); where offsetof is a macro and thus the comma between a and b is treated as a separator. So there's a part of me that wonders if we want to also support diagnosing this case. But then we'd have to look at the declarator context more recursively to see whether any of the contexts on the stack are an offsetof context and that might be tricky.

Thoughts?

inclyc added inline comments.Sep 14 2022, 10:14 AM
clang/include/clang/Parse/Parser.h
2313

Emm, these checks just return as the same as "type_specifier". Because that's what we passed into "ParsingTypename" before.

clang/test/Sema/offsetof.c
79 ↗(On Diff #459634)

FWIW, gcc seems just rejects all definitions in this context. (Perhaps during Parsing the statements). If we add a bool state to the Parser (just using RAII object as before) struct B will trigger diagnostic error because the state "ParsingOffsetof" is passed into inner declaration.

aaron.ballman added inline comments.Sep 14 2022, 11:52 AM
clang/include/clang/Parse/Parser.h
2313

Hmmm, that's certainly reasonable. Can you add the test case and make sure the behavior doesn't change?

clang/test/Sema/offsetof.c
79 ↗(On Diff #459634)

GCC accepts currently: https://godbolt.org/z/oEvzjW6Ee but you're correct regarding switching back to an RAII object being an easier way to address the nested declarations.

Let me think on this situation a bit....

inclyc added inline comments.Sep 14 2022, 6:00 PM
clang/test/Sema/offsetof.c
79 ↗(On Diff #459634)

GCC accepts currently

C++: https://godbolt.org/z/fon8e7dzf

79 ↗(On Diff #459634)
<source>: In function 'int main()':
<source>:3:3: error: types may not be defined within '__builtin_offsetof'
    3 |   {
      |   ^
<source>:6:5: error: types may not be defined within '__builtin_offsetof'
    6 |     {
      |     ^
Compiler returned: 1
aaron.ballman added inline comments.Sep 15 2022, 10:29 AM
clang/test/Sema/offsetof.c
79 ↗(On Diff #459634)

C++ is a different language in this case though. In C, you can generally define types anywhere you can spell a type, and in C++ you cannot. e.g., void func(struct S { int x, y; } s); is valid in C and invalid in C++.

inclyc added inline comments.Sep 15 2022, 6:36 PM
clang/test/Sema/offsetof.c
79 ↗(On Diff #459634)

GCC explicitly reject type definitions since GCC 8 (in C++ mode). I guess the logic here in GCC may also add a boolean state parameter to parser.

Interestingly, in C++ we treat the first parameter of __builtin_offsetof as a type specifier, rejecting the definition of struct A, but not rejecting nested definition struct B

https://godbolt.org/z/PqWjzqqYn

Emm, so, how about switch back to RAIIObject to support diagnosing nested definitions?

aaron.ballman added inline comments.Sep 16 2022, 5:21 AM
clang/test/Sema/offsetof.c
79 ↗(On Diff #459634)

Interestingly, in C++ we treat the first parameter of __builtin_offsetof as a type specifier, rejecting the definition of struct A, but not rejecting nested definition struct B

Yeah, that is interesting!

Emm, so, how about switch back to RAIIObject to support diagnosing nested definitions?

I'm getting more comfortable with that approach. Please be sure to add C++ tests to make sure we diagnose in C and C++ the same way in terms of nested structures. Thank you for exploring the approaches with me!

inclyc updated this revision to Diff 461463.Sep 19 2022, 9:54 PM

Switch back to RAIIObject.

Currently clang could not generate diagnostic messages for nested definitions
in C++. I believe using RAIIObject here is logically correct, but in C++ mode,
ActOnTag returns nullptr, and the comment says

We can't recover well from the cases where we make the type anonymous

/* SemaDecl.cpp Sema::ActOnTag Ln 17189 */
// In C++, don't return an invalid declaration. We can't recover well from
// the cases where we make the type anonymous.
if (Invalid && getLangOpts().CPlusPlus) {
  if (New->isBeingDefined())
    if (auto RD = dyn_cast<RecordDecl>(New))
      RD->completeDefinition();
  return nullptr;
} else if (SkipBody && SkipBody->ShouldSkip) {
  return SkipBody->Previous;
} else {
  return New;
}

I believe the state "ParsingBuiltinOffsetof" is correctly passed into
ParseCXXMemberSpecification (parsing nested definition), and if clang
recovers invalid declaration in the furture, nested definitions will be caught.

if (TUK == Sema::TUK_Definition) {
  assert(Tok.is(tok::l_brace) ||
         (getLangOpts().CPlusPlus && Tok.is(tok::colon)) ||
         isClassCompatibleKeyword());
  if (SkipBody.ShouldSkip)
    SkipCXXMemberSpecification(StartLoc, AttrFixitLoc, TagType,
                               TagOrTempResult.get());
  else if (getLangOpts().CPlusPlus)
    ParseCXXMemberSpecification(StartLoc, AttrFixitLoc, attrs, TagType,
                                TagOrTempResult.get());  // <----  nullptr, nested declaration skipped
  else {
    Decl *D =
        SkipBody.CheckSameAsPrevious ? SkipBody.New : TagOrTempResult.get();
    // Parse the definition body.
    ParseStructUnionBody(StartLoc, TagType, cast<RecordDecl>(D));
    if (SkipBody.CheckSameAsPrevious &&
        !Actions.ActOnDuplicateDefinition(TagOrTempResult.get(), SkipBody)) {
      DS.SetTypeSpecError();
      return;
    }
  }
}
inclyc marked 7 inline comments as done.Sep 19 2022, 10:01 PM
inclyc marked an inline comment as done.
aaron.ballman added inline comments.Sep 23 2022, 6:48 AM
clang/docs/ReleaseNotes.rst
301–302

You should move this one down to the C2x Feature Support section instead, since it's a C2x paper.

clang/include/clang/Basic/DiagnosticSemaKinds.td
1650

We might want this change, we might not -- can you test the diagnostic behavior when using #include <stddef.h>? Does it print __builtin_offsetof in the following example?

#include <stddef.h>

int main() {
  return offsetof(struct S { int a; }, a);
}

when executed with clang -fsyntax-only -ffreestanding -std=c2x test.c

If it prints the builtin name, I think we'll want to look at the builtin token to see if it was expanded from a macro named offsetof to improve the diagnostic quality.

clang/lib/Sema/SemaDecl.cpp
17044

You should be able to pass in the TagDecl directly because the diagnostics engine knows how to print a NamedDecl.

clang/test/Sema/offsetof.c
73–75 ↗(On Diff #461822)

Can you move this into a test named clang/test/C/C2x/n2350.c which looks like the other tests in that directory? That's the testing directory we're putting some basic validation tests for C papers we've implemented so that we can better track what features we claim to support.

clang/test/SemaCXX/offsetof.cpp
93

I'd like a FIXME comment here about wanting to diagnose this someday.

Emm, is it necessary to add a LangOpts check so that this change only applies to c2x? If clang was invoked without -std=c2x, should we just accept offsetof with definitions?

clang/include/clang/Basic/DiagnosticSemaKinds.td
1650
local/offsetofcc.c:4:26: error: 'struct S' cannot be defined in '__builtin_offsetof'
  return offsetof(struct S { int a; }, a);
                         ^
1 error generated.

If it prints the builtin name, I think we'll want to look at the builtin token to see if it was expanded from a macro named offsetof to improve the diagnostic quality.

OK

Emm, is it necessary to add a LangOpts check so that this change only applies to c2x? If clang was invoked without -std=c2x, should we just accept offsetof with definitions?

No, I think we should treat this as a defect report and have the behavior be the same in all versions of C.

clang/include/clang/Basic/DiagnosticSemaKinds.td
1650
inclyc added inline comments.Sep 23 2022, 8:35 AM
clang/include/clang/Basic/DiagnosticSemaKinds.td
1650

We have similar code for this here:

Wow! Thank you so much for this. I'm searching for how to do this in a LOT of doxygen generated pages (

aaron.ballman added inline comments.Sep 23 2022, 8:38 AM
clang/include/clang/Basic/DiagnosticSemaKinds.td
1650

No problem! I realized "this could be tricky, surely we've done this before" and went looking. :-D

LGTM but I will Aaron give the final approval.

inclyc updated this revision to Diff 462680.Sep 24 2022, 10:10 AM

Address comments.

Clang will now consider __builtin_offsetof #defined from "offsetof" to improve
diagnostic message.

For example:

#define offsetof(t, d) __builtin_offsetof(t, d)

int main() {
  return offsetof(struct S { int a; }, a);
}
local/offsetof.c:4:26: error: 'S' cannot be defined in 'offsetof'
  return offsetof(struct S { int a; }, a);
                         ^
1 error generated.

Emm, the "expected-error" of struct B within a macro seems have to be annotated
at the same line as"struct A".

int macro(void) {
  return offsetof(struct A // expected-error{{'A' cannot be defined in 'offsetof'}}
                           // expected-error@-1{{'B' cannot be defined in 'offsetof'}}     <---- Have to write this here, but I believe the line number is correct
  { 
    int a;
    struct B // FIXME: verifier seems to think the error is emitted by the macro
             // In fact the location of the error is "B" on the line above
    {
      int c;
      int d;
    } x;
  }, a);
}
clang/test/C/C2x/n2350.c:11:36: error: 'A' cannot be defined in '__builtin_offsetof'
  return __builtin_offsetof(struct A // expected-error{{'A' cannot be defined in '__builtin_offsetof'}} 
                                   ^
clang/test/C/C2x/n2350.c:14:12: error: 'B' cannot be defined in '__builtin_offsetof'
    struct B // expected-error{{'B' cannot be defined in '__builtin_offsetof'}} 
           ^
clang/test/C/C2x/n2350.c:26:26: error: 'A' cannot be defined in 'offsetof'
  return offsetof(struct A // expected-error{{'A' cannot be defined in 'offsetof'}}
                         ^
clang/test/C/C2x/n2350.c:30:12: error: 'B' cannot be defined in 'offsetof' <-- note that this line number is "30" (not "26")
    struct B // FIXME: verifier seems to think the error is emitted by the macro
           ^
4 errors generated.
inclyc marked 6 inline comments as done.Sep 25 2022, 7:02 AM

Hi @aaron.ballman, I've noticed in the linux kernel, type alignment was implemented by a tricky way using offsetof.

#define TYPE_ALIGN(TYPE) offsetof(struct { char x; TYPE test; }, test)

Does this always has the same semantic with C11 _Alignof? If this is not true, I think unfortunately we may emit a switchable warning instead of an error to preserve semantics here.

Hi @aaron.ballman, I've noticed in the linux kernel, type alignment was implemented by a tricky way using offsetof.

#define TYPE_ALIGN(TYPE) offsetof(struct { char x; TYPE test; }, test)

Does this always has the same semantic with C11 _Alignof? If this is not true, I think unfortunately we may emit a switchable warning instead of an error to preserve semantics here.

Technically there's no requirement that they return the same value (the structure could insert arbitrary padding, including no padding), so it's theoretically possible they return different values. But I can't think of a situation in which you'd get a different answer from TYPE_ALIGN as you would get from _Alignof.

@nickdesaulniers any thoughts here since this can impact the Linux kernel?

clang/include/clang/Parse/Parser.h
252–257
clang/include/clang/Sema/Sema.h
3293

Instead of passing two bools, why not pass Parser::OffsetOfStateKind directly?

inclyc added inline comments.Sep 26 2022, 8:22 AM
clang/include/clang/Sema/Sema.h
3293

Parser::OffsetOfStateKind is not visible to class Sema?

aaron.ballman added inline comments.Sep 26 2022, 8:55 AM
clang/include/clang/Sema/Sema.h
3293

Sure, but it's a new enum, so we can put it into Sema if we want.

inclyc updated this revision to Diff 462940.Sep 26 2022, 9:27 AM

Address comments from @aaron.ballman

Move OffsetOfKind to Sema and pass it to Sema:ActOnTag directly.

inclyc marked 3 inline comments as done.Sep 26 2022, 9:27 AM
inclyc updated this revision to Diff 462942.Sep 26 2022, 9:31 AM

Fix comment nits

aaron.ballman accepted this revision.Sep 26 2022, 12:41 PM
aaron.ballman added a subscriber: nathanchance.

LGTM, thank you! Please don't land until you have some indication from the kernel folks that this won't be super disruptive for them. CC @nickdesaulniers and @nathanchance for awareness.

This revision is now accepted and ready to land.Sep 26 2022, 12:41 PM

LGTM, thank you! Please don't land until you have some indication from the kernel folks that this won't be super disruptive for them. CC @nickdesaulniers and @nathanchance for awareness.

Thank you a lot for the heads up! I see an in-flight change around this from YingChi on the mailing list:

https://lore.kernel.org/20220925153151.2467884-1-me@inclyc.cn/

It would be good to have that change accepted into a maintainer's tree and on its way to mainline (Linus's tree) and by extension, the stable releases before merging this into main, as we and several other groups are actively testing all Linux branches with LLVM main to catch other regressions and this error would require patching of our CI, which we can definitely do but prefer to avoid because of the maintenance overhead (we try to carry zero patches at all times).

I am still running my set of builds against the kernel with this LLVM change and the aforementioned Linux change but I do see another error:

drivers/media/platform/nvidia/tegra-vde/v4l2.c:816:49: error: '' cannot be defined in 'offsetof'
        ctx = kzalloc(offsetof(struct tegra_ctx, ctrls[ARRAY_SIZE(ctrl_cfgs)]),
                                                       ^
include/linux/kernel.h:55:59: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
                                                          ^
include/linux/compiler.h:240:28: note: expanded from macro '__must_be_array'
#define __must_be_array(a)      BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
                                ^
include/linux/build_bug.h:16:44: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
                                           ^
1 error generated.

I will report back with any additional problems found.

LGTM, thank you! Please don't land until you have some indication from the kernel folks that this won't be super disruptive for them. CC @nickdesaulniers and @nathanchance for awareness.

Thank you a lot for the heads up! I see an in-flight change around this from YingChi on the mailing list:

https://lore.kernel.org/20220925153151.2467884-1-me@inclyc.cn/

It would be good to have that change accepted into a maintainer's tree and on its way to mainline (Linus's tree) and by extension, the stable releases before merging this into main, as we and several other groups are actively testing all Linux branches with LLVM main to catch other regressions and this error would require patching of our CI, which we can definitely do but prefer to avoid because of the maintenance overhead (we try to carry zero patches at all times).

I am still running my set of builds against the kernel with this LLVM change and the aforementioned Linux change but I do see another error:

drivers/media/platform/nvidia/tegra-vde/v4l2.c:816:49: error: '' cannot be defined in 'offsetof'

^ perhaps we can say something about an anonymous struct rather than print an empty name?

Thanks for the consideration and the kernel patch. Patching the kernel and clang is exceptional, going "above and beyond." Unless we are in a rush to land this, having a little more time for feedback from the kernel thread linked above I think would be good.

In particular, I was surprised by the distinction between __alignof__ and _Alignof semantically.

LGTM, thank you! Please don't land until you have some indication from the kernel folks that this won't be super disruptive for them. CC @nickdesaulniers and @nathanchance for awareness.

Thank you a lot for the heads up! I see an in-flight change around this from YingChi on the mailing list:

https://lore.kernel.org/20220925153151.2467884-1-me@inclyc.cn/

It would be good to have that change accepted into a maintainer's tree and on its way to mainline (Linus's tree) and by extension, the stable releases before merging this into main, as we and several other groups are actively testing all Linux branches with LLVM main to catch other regressions and this error would require patching of our CI, which we can definitely do but prefer to avoid because of the maintenance overhead (we try to carry zero patches at all times).

I don't think there's a rush to land this immediately, so we can definitely wait for you to give the all-clear.

I am still running my set of builds against the kernel with this LLVM change and the aforementioned Linux change but I do see another error:

drivers/media/platform/nvidia/tegra-vde/v4l2.c:816:49: error: '' cannot be defined in 'offsetof'
        ctx = kzalloc(offsetof(struct tegra_ctx, ctrls[ARRAY_SIZE(ctrl_cfgs)]),
                                                       ^
include/linux/kernel.h:55:59: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
                                                          ^
include/linux/compiler.h:240:28: note: expanded from macro '__must_be_array'
#define __must_be_array(a)      BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
                                ^
include/linux/build_bug.h:16:44: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
                                           ^
1 error generated.

I will report back with any additional problems found.

Oh wow, that's a fun one for a few reasons. 1) Oops, we print '' instead of mention that it's an anonymous struct, 2) that structure is actually declared in the scope surrounding the sizeof so it is technically being defined within offsetof, but 3) The standard requirement is "If the specified type defines a new type or if the specified member is a bit-field, the behavior is undefined." where "type" is the first parameter of the offsetof macro and this example does not define a new type there.

So I *think* this situation is actually a false positive.

inclyc updated this revision to Diff 463063.Sep 26 2022, 6:01 PM

This revision fixes:

anonymous struct

You should be able to pass in the TagDecl directly because the diagnostics
engine knows how to print a NamedDecl.

I've switch back to using Context.getTagDeclType(New) because this can print
anonymous pretty.

clang/test/C/C2x/n2350.c:23:29: error: 'struct (unnamed at clang/test/C/C2x/n2350.c:23:29)' cannot be defined in '__builtin_offsetof'
  return __builtin_offsetof(struct // expected-error-re{{'struct (unnamed at {{.*}})' cannot be defined in '__builtin_offsetof'}}

definitions within the second parameter

I've add a new test case for this. This bug is caused by the RAIIObject having
incorrect scope.

inclyc edited the summary of this revision. (Show Details)Sep 26 2022, 6:05 PM

This revision fixes:

anonymous struct

You should be able to pass in the TagDecl directly because the diagnostics
engine knows how to print a NamedDecl.

I've switch back to using Context.getTagDeclType(New) because this can print
anonymous pretty.

clang/test/C/C2x/n2350.c:23:29: error: 'struct (unnamed at clang/test/C/C2x/n2350.c:23:29)' cannot be defined in '__builtin_offsetof'
  return __builtin_offsetof(struct // expected-error-re{{'struct (unnamed at {{.*}})' cannot be defined in '__builtin_offsetof'}}

Thanks! I was very surprised we didn't print the anonymous decl properly from the decl itself, so it looks like we have the same bug in other places as well: https://godbolt.org/z/16vP3voTW

definitions within the second parameter

I've add a new test case for this. This bug is caused by the RAIIObject having
incorrect scope.

Thanks!

Diff 463063 looks good against the Linux kernel with https://lore.kernel.org/20220925153151.2467884-1-me@inclyc.cn/ applied. I see no additional errors/warnings and the drivers/media/platform/nvidia/tegra-vde/v4l2.c did disappear. Once that patch has been fully chased and accepted, this change should be able to be merged without any problems. Thank you again for taking a look at the kernel ahead of time, it is very much appreciated!

brooks added a subscriber: brooks.Sep 27 2022, 9:17 AM