On Tue, Nov 12, 2024 at 08:52:26PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 12, 2024 at 09:56:20AM -0800, Sean Christopherson wrote:
>
> > This likely needs to be addressed in whatever chunk of code is enforcing the
> > namespaces. The s/-/_ behavior (and vice versa!) is *very* baked into the
On Tue, Nov 12, 2024 at 09:56:20AM -0800, Sean Christopherson wrote:
> This likely needs to be addressed in whatever chunk of code is enforcing the
> namespaces. The s/-/_ behavior (and vice versa!) is *very* baked into the
> kernel
> at this point, e.g. parameqn() will happily parse dashes or u
On Tue, Nov 12, 2024, Peter Zijlstra wrote:
> On Mon, Nov 11, 2024 at 04:48:58PM -0800, Sean Christopherson wrote:
> > On Mon, Nov 11, 2024, Peter Zijlstra wrote:
> > > Hi!
> > >
> > > Implement a means for exports to be available only to an explicit list of
> > > named
> > > modules. By explicit
On Mon, Nov 11, 2024 at 04:48:58PM -0800, Sean Christopherson wrote:
> On Mon, Nov 11, 2024, Peter Zijlstra wrote:
> > Hi!
> >
> > Implement a means for exports to be available only to an explicit list of
> > named
> > modules. By explicitly limiting the usage of certain exports, the abuse
> > po
On Mon, Nov 11, 2024, Peter Zijlstra wrote:
> Hi!
>
> Implement a means for exports to be available only to an explicit list of
> named
> modules. By explicitly limiting the usage of certain exports, the abuse
> potential/risk is greatly reduced.
>
> The first three 'patches' clean up the existi
Hi!
Implement a means for exports to be available only to an explicit list of named
modules. By explicitly limiting the usage of certain exports, the abuse
potential/risk is greatly reduced.
The first three 'patches' clean up the existing export namespace code along the
same lines of 33def8498fdd
6 matches
Mail list logo
