Re: [PATCH] virtio_console: fix misc probe bugs
On Mon, Sep 16, 2024 at 02:32:56PM -0400, Michael S. Tsirkin wrote:
> This fixes the following issue discovered by code review:
>
> after vqs have been created, a buggy device can send an interrupt.
>
> A control vq callback will then try to schedule control_work which has
> not been initialized yet. Similarly for config interrupt. Further, in
> and out vq callbacks invoke find_port_by_vq which attempts to take
> ports_lock which also has not been initialized.
>
> To fix, init all locks and work before creating vqs.
>
> Fixes: 17634ba25544 ("virtio: console: Add a new MULTIPORT feature, support
> for generic ports")
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/char/virtio_console.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You have marked a patch with a "Fixes:" tag for a commit that is in an
older released kernel, yet you do not have a cc: stable line in the
signed-off-by area at all, which means that the patch will not be
applied to any older kernel releases. To properly fix this, please
follow the documented rules in the
Documentation/process/stable-kernel-rules.rst file for how to resolve
this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
Re: [PATCH v2 16/19] gendwarfksyms: Add support for reserved structure fields
On Thu, Aug 22, 2024 at 12:00:15PM +, Benno Lossin wrote: > > Here's one example in the android tree where 4 64bit fields are reserved > > for future abi changes: > > > > https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/include/linux/fs.h#421 > > > > And here's a different place where a field is being used with many > > remaining for future use: > > > > https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/include/linux/sched.h#1379 > > > > And also, we want/need lots of other space reservation at times, look at > > how "Others" can get access to reserved areas in structures that need to > > be done in an abi-safe way: > > > > https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/include/linux/sched.h#1375 > > Let me correct myself, it's only possible to replace one `KAbiReserved` > by one new field. You can have as many fields of type `KAbiReserved` as > you want. The thing that you can't do is replace a single `KAbiReserved` > field by multiple (well you can, but then you have to change the sites > that use it). That's odd/foolish, why would that be the case? Isn't that exactly what a union is for? How are you going to know ahead of time what size types to save space for? All we really want to do here is "pad out this structure by X bytes" and then later "take X bytes to represent this variable" at a later point in time. Surely rust can do that, right? :) > > All of this also needs to be possible in any structures that are > > exported by rust code if vendors want to have a way to track and ensure > > that abis do not change over time, just like they can today in C code. > > All of those structs need to be `repr(C)`, otherwise they don't > have a stable layout to begin with. Do we have any way to enforce at build time that exports from rust code are in this format to ensure that this will work properly going forward? I guess someone is going to have to write the first api in rust that actually gets used before we worry about this... thanks, greg k-h
Re: [PATCH v2 16/19] gendwarfksyms: Add support for reserved structure fields
On Thu, Aug 22, 2024 at 05:55:32AM +, Benno Lossin wrote:
> On 22.08.24 01:29, Greg Kroah-Hartman wrote:
> > On Wed, Aug 21, 2024 at 11:31:25AM +, Benno Lossin wrote:
> >> On 20.08.24 22:03, Matthew Maurer wrote:
> >>>>> The way `KAbiReserved` is implemented is via a `union` (maybe a bit
> >>>>> ironic, considering what I said in my other replies, but in this case,
> >>>>> we would provide a safe abstraction over this `union`, thus avoiding
> >>>>> exposing users of this type to `unsafe`):
> >>>>>
> >>>>> #[repr(C)]
> >>>>> pub union KAbiReserved {
> >>>>> value: T,
> >>>>> _reserved: R,
> >>>>> }
> >>>>
> >>>> I like this approach even better, assuming any remaining issues with
> >>>> ownership etc. can be sorted out. This would also look identical to
> >>>> the C version in DWARF if you rename _reserved in the union to
> >>>> __kabi_reserved. Of course, we can always change gendwarfksyms to
> >>>> support a different scheme for Rust code if a better solution comes
> >>>> along later.
> >>
> >> Yeah sure, that should also then work directly with this patch, right?
> >>
> >>>> Sami
> >>>
> >>> Agreement here - this seems like a good approach to representing
> >>> reserved in Rust code. A few minor adjustments we discussed off-list
> >>> which aren't required for gendwarfksyms to know about:
> >>> 1. Types being added to reserved fields have to be `Copy`, e.g. they
> >>> must be `!Drop`.
> >>> 2. Types being added to reserved fields must be legal to be
> >>> represented by all zeroes.
> >>> 3. Reserved fields need to be initialized to zero before having their
> >>> union set to the provided value when constructing them.
> >>> 4. It may be helpful to have delegating trait implementations to avoid
> >>> the couple places where autoderef won't handle the conversion.
> >>>
> >>> While I think this is the right solution, esp. since it can share a
> >>> representation with C, I wanted to call out one minor shortfall - a
> >>> reserved field can only be replaced by one type. We could still
> >>> indicate a replacement by two fields the same as in C, by using a
> >>> tuple which will look like an anonymous struct. The limitation will be
> >>> that if two or more new fields were introduced, we'd need to edit the
> >>> patches accessing them to do foo.x.y and foo.x.z for their accesses
> >>> instead of simply foo.y and foo.z - the autoref trick only works for a
> >>> single type.
> >>
> >> We will have to see how often multiple fields are added to a struct. If
> >> they are infrequent and it's fine for those patches to then touch the
> >> field accesses, then I think we can just stick with this approach.
> >> If there are problems with that, we can also try the following:
> >> all fields of kABI structs must be private and must only be accessed
> >> through setters/getters. We can then modify the body the setters/getters
> >> to handle the additional indirection.
> >
> > That's just not going to work, sorry. Remember, the goal here is to
> > keep the code that comes from kernel.org identical to what you have in
> > your "enterprise" kernel tree, with the exception of the few extra
> > "padding" fields you have added to allow for changes in the future in
> > the kernel.org versions.
>
> Yeah, that's what I thought.
>
> > Requiring all kernel.org changes that add a new field to a structure to
> > only do so with a settter/getter is going to just not fly at all as they
> > will not care one bit.
> >
> > Or, we can just forget about "abi stability" for rust code entirely,
> > which I am totally fine with. It's something that managers seem to like
> > for a "check box" but in reality, no one really needs it (hint, vendors
> > rebuild their code anyway.)
>
> The approach already works for a adding a single field and I got from
> the discussions with Matthew and Sami that that is the most common case.
> We will reach out to the Rust folks and see what we can do about the
> multiple field case.
No, single field is NOT the common case, the common case is reserving
multiple padding variables in a structure as lots of things can chang
Re: [PATCH v2 16/19] gendwarfksyms: Add support for reserved structure fields
On Wed, Aug 21, 2024 at 11:31:25AM +, Benno Lossin wrote:
> On 20.08.24 22:03, Matthew Maurer wrote:
> >>> The way `KAbiReserved` is implemented is via a `union` (maybe a bit
> >>> ironic, considering what I said in my other replies, but in this case,
> >>> we would provide a safe abstraction over this `union`, thus avoiding
> >>> exposing users of this type to `unsafe`):
> >>>
> >>> #[repr(C)]
> >>> pub union KAbiReserved {
> >>> value: T,
> >>> _reserved: R,
> >>> }
> >>
> >> I like this approach even better, assuming any remaining issues with
> >> ownership etc. can be sorted out. This would also look identical to
> >> the C version in DWARF if you rename _reserved in the union to
> >> __kabi_reserved. Of course, we can always change gendwarfksyms to
> >> support a different scheme for Rust code if a better solution comes
> >> along later.
>
> Yeah sure, that should also then work directly with this patch, right?
>
> >> Sami
> >
> > Agreement here - this seems like a good approach to representing
> > reserved in Rust code. A few minor adjustments we discussed off-list
> > which aren't required for gendwarfksyms to know about:
> > 1. Types being added to reserved fields have to be `Copy`, e.g. they
> > must be `!Drop`.
> > 2. Types being added to reserved fields must be legal to be
> > represented by all zeroes.
> > 3. Reserved fields need to be initialized to zero before having their
> > union set to the provided value when constructing them.
> > 4. It may be helpful to have delegating trait implementations to avoid
> > the couple places where autoderef won't handle the conversion.
> >
> > While I think this is the right solution, esp. since it can share a
> > representation with C, I wanted to call out one minor shortfall - a
> > reserved field can only be replaced by one type. We could still
> > indicate a replacement by two fields the same as in C, by using a
> > tuple which will look like an anonymous struct. The limitation will be
> > that if two or more new fields were introduced, we'd need to edit the
> > patches accessing them to do foo.x.y and foo.x.z for their accesses
> > instead of simply foo.y and foo.z - the autoref trick only works for a
> > single type.
>
> We will have to see how often multiple fields are added to a struct. If
> they are infrequent and it's fine for those patches to then touch the
> field accesses, then I think we can just stick with this approach.
> If there are problems with that, we can also try the following:
> all fields of kABI structs must be private and must only be accessed
> through setters/getters. We can then modify the body the setters/getters
> to handle the additional indirection.
That's just not going to work, sorry. Remember, the goal here is to
keep the code that comes from kernel.org identical to what you have in
your "enterprise" kernel tree, with the exception of the few extra
"padding" fields you have added to allow for changes in the future in
the kernel.org versions.
Requiring all kernel.org changes that add a new field to a structure to
only do so with a settter/getter is going to just not fly at all as they
will not care one bit.
Or, we can just forget about "abi stability" for rust code entirely,
which I am totally fine with. It's something that managers seem to like
for a "check box" but in reality, no one really needs it (hint, vendors
rebuild their code anyway.)
thanks,
greg k-h
Re: [PATCH v2 16/19] gendwarfksyms: Add support for reserved structure fields
On Sat, Aug 17, 2024 at 01:19:55PM +, Benno Lossin wrote:
> On 17.08.24 09:41, Greg Kroah-Hartman wrote:
> > On Fri, Aug 16, 2024 at 08:50:53AM -0700, Sami Tolvanen wrote:
> >> On Fri, Aug 16, 2024 at 12:20 AM Greg Kroah-Hartman
> >> wrote:
> >>> On Thu, Aug 15, 2024 at 05:39:20PM +, Sami Tolvanen wrote:
> >>> Especially as I have no idea how you are going to do
> >>> this with the rust side of things, this all will work for any structures
> >>> defined in .rs code, right?
> >>
> >> Yes, Rust structures can use the same scheme. Accessing union members
> >> might be less convenient than in C, but can presumably be wrapped in
> >> helper macros if needed.
> >
> > That feels ripe for problems for any rust code as forcing a helper macro
> > for a "normal" access to a structure field is going to be a lot of churn
> > over time. Is the need for a macro due to the fact that accessing a
> > union is always considered "unsafe" in rust? If that's the case, ick,
> > this is going to get even messier even faster as the need for sprinkling
> > unsafe accesses everywhere for what used to be a normal/safe one will
> > cause people to get nervous...
>
> The reason for union field access being unsafe in Rust is that you can
> easily shoot yourself in the foot. For example:
>
> union Foo {
> a: bool,
> b: i32,
> }
>
> let foo = Foo { b: 3 };
> println!("{}", unsafe { foo.a });
>
> This is UB, since `3` is of course not a valid value for `bool`. With
> unions the compiler doesn't know which variant is active.
Understood, then why attempt to use a union for this type of "abi safe
padding"?
> Since unions are unsafe in Rust, we don't really use them directly (in
> the `kernel` crate, we have 0 union definitions). Instead we use certain
> unions from the stdlib such as `MaybeUninit`. But the fields of that
> union are private and never accessed.
>
> In general, unions in Rust are very important primitive types, but they
> are seldomly used directly. Instead enums are used a lot more, since you
> don't need to roll your own tagged unions.
>
> For this use-case (the one in the patch), I don't really know if we want
> to copy the approach from C. Do we even support exporting kABI from
> Rust?
That's the goal here, you want to create an abi that can change over
time without "breaking" the abi. Usually this is just adding additional
padding in structures to have room for new additions.
> If yes, then we I would recommend we tag it in the source code
> instead of using a union. Here the example from the patch adapted:
>
> #[repr(C)] // needed for layout stability
> pub struct Struct1 {
> a: u64,
> #[kabi_reserved(u64)] // this marker is new
> _reserved: u64,
> }
>
> And then to use the reserved field, you would do this:
>
> #[repr(C)]
> pub struct Struct1 {
> a: u64,
> #[kabi_reserved(u64)]
> b: Struct2,
> }
>
> #[repr(C)]
> pub struct Struct2 {
> b: i32,
> v: i32,
> }
>
> The attribute would check that the size of the two types match and
> gendwarfksyms would use the type given in "()" instead of the actual
> type.
Remember the "goal" here is to NOT have to modify the places in the
kernel that use the new field in the structure, but for that to "just
work". Your change here wouldn't allow that as any use of the new "b"
field would have to be through something in "Struct2", not directly in
Struct1, right?
We can mess with the structure definitions but we should not have to
touch the places where the structure fields are used at all. If that's
going to be a requirement (as it sounds like it would with the use of
unsafe in the union), then this is not going to be a solution at all.
thanks,
greg k-h
Re: [PATCH v2 16/19] gendwarfksyms: Add support for reserved structure fields
On Fri, Aug 16, 2024 at 08:50:53AM -0700, Sami Tolvanen wrote:
> Hi Greg,
>
> On Fri, Aug 16, 2024 at 12:20 AM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Aug 15, 2024 at 05:39:20PM +, Sami Tolvanen wrote:
> > > Distributions that want to maintain a stable kABI need the ability to
> > > add reserved fields to kernel data structures that they anticipate
> > > will be modified during the ABI support timeframe, either by LTS
> > > updates or backports.
> > >
> > > With genksyms, developers would typically hide changes to the reserved
> > > fields from version calculation with #ifndef __GENKSYMS__, which would
> > > result in the symbol version not changing even though the actual type
> > > of the reserved field changes. When we process precompiled object
> > > files, this is again not an option.
> > >
> > > To support stable symbol versions for reserved fields, change the
> > > union type processing to recognize field name prefixes, and if the
> > > union contains a field name that starts with __kabi_reserved, only use
> > > the type of that field for computing symbol versions. In other words,
> > > let's assume we have a structure where we want to reserve space for
> > > future changes:
> > >
> > > struct struct1 {
> > > long a;
> > > long __kabi_reserved_0; /* reserved for future use */
> > > };
> > > struct struct1 exported;
> > >
> > > gendwarfksyms --debug produces the following output:
> > >
> > > variable structure_type struct1 {
> > > member base_type long int byte_size(8) encoding(5)
> > > data_member_location(0),
> > > member base_type long int byte_size(8) encoding(5)
> > > data_member_location(8),
> > > } byte_size(16);
> > > #SYMVER exported 0x67997f89
> > >
> > > To take the reserved field into use, a distribution would replace it
> > > with a union, with one of the fields keeping the __kabi_reserved name
> > > prefix for the original type:
> > >
> > > struct struct1 {
> > > long a;
> > > union {
> > > long __kabi_reserved_0;
> > > struct {
> > > int b;
> > > int v;
> > > };
> > > };
> > >
> >
> > Ah, ignore my previous email, here's the --stable stuff.
> >
> > But this all needs to go into some documentation somewhere, trying to
> > dig it out of a changelog is going to be impossible to point people at.
>
> I agree, which is why I included the details in the comments too.
> There's also an example file if you scroll down a bit further, but I
> can certainly add some actual documentation too. Since the --stable
> bits are not really needed in the mainline kernel, do you prefer a
> file in Documentation/ or is it sufficient to expand the example files
> to include any missing details?
Ah, I missed the examples, I thought that was a test for the feature :)
Yes, it needs to be documented somewhere, and usually documentation is
in Documentation/ so that it shows up on the web and everywhere else.
> > > +/* See dwarf.c:process_reserved */
> > > +#define RESERVED_PREFIX "__kabi_reserved"
> >
> > Seems semi-sane, I can live with this.
>
> Is there something you'd change to make this more than semi-sane?
I can't think of it, but perhaps we need a check somewhere to ensure
that these symbol names do NOT end up in the main kernel tree?
Or just keep this whole patch as an add-on on the end that is only
applied by the distro kernels and is not merged into mainline at all?
> > I don't know if you want to take the next step and provide examples of
> > how to use this in "easy to use macros" for it all, but if so, that
> > might be nice.
>
> This should already work with the macros Android uses, for example,
> with minor changes. The current example file doesn't include macro
> wrappers, but I can add them in the next version.
The Android macros are a copy of what SLES and RHEL does so that's good.
And yes, an example macro would be nice so we all don't have to reinvent
it yet-again like we have done already. Consolidation is nice.
> > Especially as I have no idea how you are going to do
> > this with the rust side of things, this all will work for any structures
> > defined in .rs code, right?
>
> Yes, Rust structures can use the same scheme. Accessing union members
> might be less convenient than in C, but can presumably be wrapped in
> helper macros if needed.
That feels ripe for problems for any rust code as forcing a helper macro
for a "normal" access to a structure field is going to be a lot of churn
over time. Is the need for a macro due to the fact that accessing a
union is always considered "unsafe" in rust? If that's the case, ick,
this is going to get even messier even faster as the need for sprinkling
unsafe accesses everywhere for what used to be a normal/safe one will
cause people to get nervous...
thanks,
greg k-h
Re: [PATCH v2 16/19] gendwarfksyms: Add support for reserved structure fields
On Thu, Aug 15, 2024 at 05:39:20PM +, Sami Tolvanen wrote:
> Distributions that want to maintain a stable kABI need the ability to
> add reserved fields to kernel data structures that they anticipate
> will be modified during the ABI support timeframe, either by LTS
> updates or backports.
>
> With genksyms, developers would typically hide changes to the reserved
> fields from version calculation with #ifndef __GENKSYMS__, which would
> result in the symbol version not changing even though the actual type
> of the reserved field changes. When we process precompiled object
> files, this is again not an option.
>
> To support stable symbol versions for reserved fields, change the
> union type processing to recognize field name prefixes, and if the
> union contains a field name that starts with __kabi_reserved, only use
> the type of that field for computing symbol versions. In other words,
> let's assume we have a structure where we want to reserve space for
> future changes:
>
> struct struct1 {
> long a;
> long __kabi_reserved_0; /* reserved for future use */
> };
> struct struct1 exported;
>
> gendwarfksyms --debug produces the following output:
>
> variable structure_type struct1 {
> member base_type long int byte_size(8) encoding(5)
> data_member_location(0),
> member base_type long int byte_size(8) encoding(5)
> data_member_location(8),
> } byte_size(16);
> #SYMVER exported 0x67997f89
>
> To take the reserved field into use, a distribution would replace it
> with a union, with one of the fields keeping the __kabi_reserved name
> prefix for the original type:
>
> struct struct1 {
> long a;
> union {
> long __kabi_reserved_0;
> struct {
> int b;
> int v;
> };
> };
>
Ah, ignore my previous email, here's the --stable stuff.
But this all needs to go into some documentation somewhere, trying to
dig it out of a changelog is going to be impossible to point people at.
> +/* See dwarf.c:process_reserved */
> +#define RESERVED_PREFIX "__kabi_reserved"
Seems semi-sane, I can live with this.
I don't know if you want to take the next step and provide examples of
how to use this in "easy to use macros" for it all, but if so, that
might be nice. Especially as I have no idea how you are going to do
this with the rust side of things, this all will work for any structures
defined in .rs code, right?
thanks,
greg k-h
Re: [PATCH v2 00/19] Implement DWARF modversions
On Thu, Aug 15, 2024 at 05:39:04PM +, Sami Tolvanen wrote: > Changes in v2: > - Per Luis' request, dropped Rust-specific patches and added > gendwarfksyms as an alternative to genksyms for the entire > kernel. > > - Added support for missing DWARF features needed to handle > also non-Rust code. > > - Changed symbol address matching to use the symbol table > information instead of relying on addresses in DWARF. > > - Added __gendwarfksyms_ptr patches to ensure the compiler emits > the necessary type information in DWARF even for symbols that > are defined in other TUs. > > - Refactored debugging output and moved the more verbose output > behind --dump* flags. > > - Added a --symtypes flag for generating a genksyms-style > symtypes output based on Petr's feedback, and refactored > symbol version calculations to be based on symtypes instead > of raw --dump-dies output. > > - Based on feedback from Greg and Petr, added --stable flag and > support for reserved data structure fields and declaration-onl > structures. Also added examples for using these features. I missed the examples for this, is there a Documentation/ update somewhere to explain this? What patch of the series handles this? thanks, greg k-h
Re: [PATCH v2 01/19] tools: Add gendwarfksyms
On Thu, Aug 15, 2024 at 05:39:05PM +, Sami Tolvanen wrote: > --- /dev/null > +++ b/scripts/gendwarfksyms/dwarf.c > @@ -0,0 +1,87 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later Sorry, but I have to ask, do you _REALLY_ mean "or later" here and in other places in this series? If so, great, but I want to be sure, as I know: > + * Copyright (C) 2024 Google LLC Has some issues with the types of licenses that marking will cover. thanks, greg k-h
Re: [PATCH] driver core: Fix a null-ptr-deref in module_add_driver()
On Mon, Aug 12, 2024 at 12:18:17PM +0200, Markus Elfring wrote: > > Inject fault while probing of-fpga-region, if kasprintf() fails in > > module_add_driver(), the second sysfs_remove_link() in exit path will cause > > null-ptr-deref as below because kernfs_name_hash() will call strlen() with > > NULL driver_name. > … > > How do you think about to use the term “null pointer dereference” > for the commit message (and summary phrase)? > > > … > > +++ b/drivers/base/module.c > > @@ -66,27 +66,31 @@ int module_add_driver(struct module *mod, const struct > > device_driver *drv) > … > > sysfs_remove_link(mk->drivers_dir, driver_name); > > + > > +out_free_driver_name: > > kfree(driver_name); > > > > +out_remove_kobj: > > + sysfs_remove_link(&drv->p->kobj, "module"); > … > > I suggest to omit two blank lines here. Hi, This is the semi-friendly patch-bot of Greg Kroah-Hartman. Markus, you seem to have sent a nonsensical or otherwise pointless review comment to a patch submission on a Linux kernel developer mailing list. I strongly suggest that you not do this anymore. Please do not bother developers who are actively working to produce patches and features with comments that, in the end, are a waste of time. Patch submitter, please ignore Markus's suggestion; you do not need to follow it at all. The person/bot/AI that sent it is being ignored by almost all Linux kernel maintainers for having a persistent pattern of behavior of producing distracting and pointless commentary, and inability to adapt to feedback. Please feel free to also ignore emails from them. thanks, greg k-h's patch email bot
Re: [PATCH 00/15] Implement MODVERSIONS for Rust
On Mon, Jul 15, 2024 at 08:39:59PM +, Sami Tolvanen wrote:
> If using unions here is acceptable to everyone, a simple solution
> would be to use a known name prefix for the reserved members and teach
> gendwarfksyms to only print out the original type for the replaced
> ones. For example:
>
> The initial placeholder:
>
> u8 __kabi_reserved_1[8];
Don't use u8, use u64 please, it makes things simpler :)
> After replacement:
>
> union {
> u64 new_member;
> struct {
> u8 __kabi_reserved_1[8];
> };
> }
Note, such a thing would only be for the distros that want it, you can
add support for this to the tool, but there is no need for any
__kabi_reserved fields in mainline.
> Here gendwarfksyms would see the __kabi_reserved prefix and only use
> u8 [8] for the CRC calculation. Does this sound reasonable?
>
> Greg, I know you've been dealing with this for a long time, any thoughts?
It's a good start, yes. Also watch out for when structures go from
"anonymous" to "fully described" when new #include lines get added to
files. The current tooling has issues with that, so we need to use
__GENKSYMS__ #ifdef lines in some places to keep crc generation stable.
Don't know if dwarf output would be susceptible to the same issues with
that or not, but you should check.
thanks,
greg k-h
Re: [PATCH v3] init: staging: Fix missing warning/taint on builtin code
On Sat, Jul 06, 2024 at 12:15:01AM -0300, Ágatha Isabelle Chris Moreira Guedes
wrote:
> Fix the absence of warning message and kernel tainting when initializing
> drivers from the `drivers/staging` subtree from initcalls (when
> configured as built-in).
>
> When such a driver is built as module and the module is loaded, the
> `load_module()` function taints the kernel to signal code of unknown
> quality is loaded, and produces a warning like this:
>
> [8.076352] rts5208: module is from the staging directory, the
> quality is unknown, you have been warned.
>
> The same behaviour is absent, however, when a staging driver is compiled
> as built-in on the kernel image, since loading it happens through
> initcalls and not through load_module().
>
> This might prevent relevant information of being available on a bug
> report (i.e. on a panic log) among other possible problems.
>
> NOTES:
> - The patch is written in such a way that all non-staging drivers are
> kept the way they were, except for staging drivers built with
> `-DSTAGING_CODE`.
That's good!
> - Since it changes some macros related to clang LTO as well, I tested it
> and it works properly in kernels compiled with both clang and gcc.
This is odd, why is it messing with LTO stuff? It should be much more
"self contained" than this I feel like.
I see what you are doing by trying to use some of the LTO macros again,
but in doing so, it makes it really hard to understand the diff and feel
comfortable with this.
If you want to stick with what you have done here, can you split it up a
bit more? Once patch for the LTO header file changes and then another
that only adds the staging stuff. That way it's easier to review and
justify that nothing is going to be broken with this patch.
> - Some `checkpatch.pl` errors, warnings and checks (with `--strict`) are
> present. Some were already there, some I introduced but I think
> they're unavoidable. Some IMHO don´t make sense at all, I think they
> would apply for most regular macros but initcall macros are just way
> different.
Yeah, checkpatch and macros can get tricky, use your best judgement here
and it looks ok.
> Fixes: 061b1bd394ca ("Staging: add TAINT_CRAP for all drivers/staging code")
I think it really fixes the commit _after_ this one that turns on the
taint for the build :)
anyway, nice work, I think it's almost there!
greg k-h
Re: [PATCH] tracing/net_sched: NULL pointer dereference in perf_trace_qdisc_reset()
On Thu, Jul 04, 2024 at 08:16:34PM +0900, Yunseong Kim wrote:
> Hi Greg, Hi Jakub
>
> On 7/4/24 6:32 오후, Greg Kroah-Hartman wrote:
> > On Wed, Jul 03, 2024 at 07:18:35PM -0700, Jakub Kicinski wrote:
> >> On Wed, 3 Jul 2024 03:01:47 +0900 Yunseong Kim wrote:
> >>> Support backports for stable version. There are two places where null
> >>> deref could happen before
> >>> commit 2c92ca849fcc ("tracing/treewide: Remove second parameter of
> >>> __assign_str()")
> >>> Link:
> >>> https://lore.kernel.org/linux-trace-kernel/20240516133454.681ba...@rorschach.local.home/
> >>>
> >>> I've checked +v6.1.82 +v6.6.22 +v6.7.10, +v6.8, +6.9, this version need
> >>> to be applied, So, I applied the patch, tested it again, and confirmed
> >>> working fine.
> >>
> >> You're missing the customary "[ Upstream commit ]"
> >> line, not sure Greg will pick this up.
> >>
> >
> > Yeah, I missed this, needs to be very obvious what is happening here.
> > I'll replace the version in the queues with this one now, thanks.
> >
> > greg k-h
>
>
> Thank you for your hard work.
>
>
> This fix need to be applied versions in +v5.10.213, +v5.15.152, +v6.1.82
> +v6.6.22, +v6.7.10, +v6.8, +6.9
>
Already done.
Re: [PATCH] tracing/net_sched: NULL pointer dereference in perf_trace_qdisc_reset()
On Wed, Jul 03, 2024 at 07:18:35PM -0700, Jakub Kicinski wrote:
> On Wed, 3 Jul 2024 03:01:47 +0900 Yunseong Kim wrote:
> > Support backports for stable version. There are two places where null
> > deref could happen before
> > commit 2c92ca849fcc ("tracing/treewide: Remove second parameter of
> > __assign_str()")
> > Link:
> > https://lore.kernel.org/linux-trace-kernel/20240516133454.681ba...@rorschach.local.home/
> >
> > I've checked +v6.1.82 +v6.6.22 +v6.7.10, +v6.8, +6.9, this version need
> > to be applied, So, I applied the patch, tested it again, and confirmed
> > working fine.
>
> You're missing the customary "[ Upstream commit ]"
> line, not sure Greg will pick this up.
>
Yeah, I missed this, needs to be very obvious what is happening here.
I'll replace the version in the queues with this one now, thanks.
greg k-h
Re: [PATCH 00/15] Implement MODVERSIONS for Rust
On Wed, Jun 19, 2024 at 01:50:36AM +0900, Masahiro Yamada wrote: > On Wed, Jun 19, 2024 at 1:44 AM Greg Kroah-Hartman > wrote: > > > > On Mon, Jun 17, 2024 at 05:58:19PM +, Sami Tolvanen wrote: > > > Hi folks, > > > > > > This series implements CONFIG_MODVERSIONS for Rust, an important > > > feature for distributions like Android that want to ship Rust > > > kernel modules, and depend on modversions to help ensure module ABI > > > compatibility. > > > > > > There have been earlier proposals [1][2] that would allow Rust > > > modules to coexist with modversions, but none that actually implement > > > symbol versioning. Unlike C, Rust source code doesn't have sufficient > > > information about the final ABI, as the compiler has considerable > > > freedom in adjusting structure layout for improved performance [3], > > > for example, which makes using a source code parser like genksyms > > > a non-starter. Based on Matt's suggestion and previous feedback > > > from maintainers, this series uses DWARF debugging information for > > > computing versions. DWARF is an established and relatively stable > > > format, which includes all the necessary ABI details, and adding a > > > CONFIG_DEBUG_INFO dependency for Rust symbol versioning seems like a > > > reasonable trade-off. > > > > > > The first 12 patches of this series add a small tool for computing > > > symbol versions from DWARF, called gendwarfksyms. When passed a list > > > of exported symbols, the tool generates an expanded type string > > > for each symbol, and computes symbol CRCs similarly to genksyms. > > > gendwarfksyms is written in C and uses libdw to process DWARF, mainly > > > because of the existing support for C host tools that use elfutils > > > (e.g., objtool). > > > > That's cool, can the C code be switched to also use this? That way we > > only have one path/code for all of this? > > > As the description says, it requires CONFIG_DEBUG_INFO. > We can strip the debug info from the final vmlinux, but > I guess the build speed will be even slower than the current genksyms. For people who want genksyms (i.e. distros), don't they normally already enable DEBUG_INFO as well? The problems of genksyms are well known and a pain (I speak from experience), so replacing it with info based on DWARF would be great, I'll gladly trade off the DEBUG_INFO issue for stablilty! thanks, greg k-h
Re: [PATCH 00/15] Implement MODVERSIONS for Rust
On Mon, Jun 17, 2024 at 05:58:19PM +, Sami Tolvanen wrote: > Hi folks, > > This series implements CONFIG_MODVERSIONS for Rust, an important > feature for distributions like Android that want to ship Rust > kernel modules, and depend on modversions to help ensure module ABI > compatibility. > > There have been earlier proposals [1][2] that would allow Rust > modules to coexist with modversions, but none that actually implement > symbol versioning. Unlike C, Rust source code doesn't have sufficient > information about the final ABI, as the compiler has considerable > freedom in adjusting structure layout for improved performance [3], > for example, which makes using a source code parser like genksyms > a non-starter. Based on Matt's suggestion and previous feedback > from maintainers, this series uses DWARF debugging information for > computing versions. DWARF is an established and relatively stable > format, which includes all the necessary ABI details, and adding a > CONFIG_DEBUG_INFO dependency for Rust symbol versioning seems like a > reasonable trade-off. > > The first 12 patches of this series add a small tool for computing > symbol versions from DWARF, called gendwarfksyms. When passed a list > of exported symbols, the tool generates an expanded type string > for each symbol, and computes symbol CRCs similarly to genksyms. > gendwarfksyms is written in C and uses libdw to process DWARF, mainly > because of the existing support for C host tools that use elfutils > (e.g., objtool). That's cool, can the C code be switched to also use this? That way we only have one path/code for all of this? thanks, greg k-h
Re: [PATCH] nvdimm: make nd_class constant
On Mon, Jun 10, 2024 at 10:44:42AM -0700, Dan Williams wrote: > Greg Kroah-Hartman wrote: > > Now that the driver core allows for struct class to be in read-only > > memory, we should make all 'class' structures declared at build time > > placing them into read-only memory, instead of having to be dynamically > > allocated at runtime. > > Change looks good to me, > > Reviewed-by: Dan Williams > > ...changelog grammar tripped me up though, how about: > > "Now that the driver core allows for struct class to be in read-only > memory, it is possible to make all 'class' structures be declared at > build time. Move the class to a 'static const' declaration and register > it rather than dynamically create it." That works too, want me to resubmit with this, or can I update it when I commit it to my tree? thanks, greg "the changelog is the hardest part" k-h
[PATCH] nvdimm: make nd_class constant
Now that the driver core allows for struct class to be in read-only
memory, we should make all 'class' structures declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at runtime.
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Cc: nvd...@lists.linux.dev
Signed-off-by: Greg Kroah-Hartman
---
drivers/nvdimm/bus.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index 508aed017ddc..101c425f3e8b 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -25,9 +25,12 @@
int nvdimm_major;
static int nvdimm_bus_major;
-static struct class *nd_class;
static DEFINE_IDA(nd_ida);
+static const struct class nd_class = {
+ .name = "nd",
+};
+
static int to_nd_device_type(const struct device *dev)
{
if (is_nvdimm(dev))
@@ -742,7 +745,7 @@ int nvdimm_bus_create_ndctl(struct nvdimm_bus *nvdimm_bus)
device_initialize(dev);
lockdep_set_class(&dev->mutex, &nvdimm_ndctl_key);
device_set_pm_not_required(dev);
- dev->class = nd_class;
+ dev->class = &nd_class;
dev->parent = &nvdimm_bus->dev;
dev->devt = devt;
dev->release = ndctl_release;
@@ -765,7 +768,7 @@ int nvdimm_bus_create_ndctl(struct nvdimm_bus *nvdimm_bus)
void nvdimm_bus_destroy_ndctl(struct nvdimm_bus *nvdimm_bus)
{
- device_destroy(nd_class, MKDEV(nvdimm_bus_major, nvdimm_bus->id));
+ device_destroy(&nd_class, MKDEV(nvdimm_bus_major, nvdimm_bus->id));
}
static const struct nd_cmd_desc __nd_cmd_dimm_descs[] = {
@@ -1320,11 +1323,9 @@ int __init nvdimm_bus_init(void)
goto err_dimm_chrdev;
nvdimm_major = rc;
- nd_class = class_create("nd");
- if (IS_ERR(nd_class)) {
- rc = PTR_ERR(nd_class);
+ rc = class_register(&nd_class);
+ if (rc)
goto err_class;
- }
rc = driver_register(&nd_bus_driver.drv);
if (rc)
@@ -1333,7 +1334,7 @@ int __init nvdimm_bus_init(void)
return 0;
err_nd_bus:
- class_destroy(nd_class);
+ class_unregister(&nd_class);
err_class:
unregister_chrdev(nvdimm_major, "dimmctl");
err_dimm_chrdev:
@@ -1347,7 +1348,7 @@ int __init nvdimm_bus_init(void)
void nvdimm_bus_exit(void)
{
driver_unregister(&nd_bus_driver.drv);
- class_destroy(nd_class);
+ class_unregister(&nd_class);
unregister_chrdev(nvdimm_bus_major, "ndctl");
unregister_chrdev(nvdimm_major, "dimmctl");
bus_unregister(&nvdimm_bus_type);
--
2.45.2
Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties
On Tue, May 14, 2024 at 06:21:57PM -0700, Yuanchu Xie wrote: > On Tue, May 14, 2024 at 9:06 AM Greg Kroah-Hartman > wrote: > > > > On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote: > > > Memctl provides a way for the guest to control its physical memory > > > properties, and enables optimizations and security features. For > > > example, the guest can provide information to the host where parts of a > > > hugepage may be unbacked, or sensitive data may not be swapped out, etc. > > >... > > Pretty generic name for a hardware-specific driver :( > It's not for real hardware btw. Its use case is similar to pvpanic > where the device is emulated by the VMM. I can change the name if it's > a problem. This file is only used for a single PCI device, that is very hardware-specific even if that hardware is "fake" :) Please make the name more specific as well. thanks, greg k-h
Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties
On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote:
> +/*
> + * Used for internal kernel memctl calls, i.e. to better support kernel
> stacks,
> + * or to efficiently zero hugetlb pages.
> + */
> +long memctl_vmm_call(__u64 func_code, __u64 addr, __u64 length, __u64 arg,
> + struct memctl_buf *buf)
> +{
> + buf->call.func_code = func_code;
> + buf->call.addr = addr;
> + buf->call.length = length;
> + buf->call.arg = arg;
> +
> + return __memctl_vmm_call(buf);
> +}
> +EXPORT_SYMBOL(memctl_vmm_call);
You export something that is never actually called, which implies that
this is not tested at all (i.e. it is dead code.) Please remove.
Also, why not EXPORT_SYMBOL_GPL()? (I have to ask, sorry.)
thanks,
greg k-h
Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties
On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote: > Memctl provides a way for the guest to control its physical memory > properties, and enables optimizations and security features. For > example, the guest can provide information to the host where parts of a > hugepage may be unbacked, or sensitive data may not be swapped out, etc. > > Memctl allows guests to manipulate its gPTE entries in the SLAT, and > also some other properties of the memory map the back's host memory. > This is achieved by using the KVM_CAP_SYNC_MMU capability. When this > capability is available, the changes in the backing of the memory region > on the host are automatically reflected into the guest. For example, an > mmap() or madvise() that affects the region will be made visible > immediately. > > There are two components of the implementation: the guest Linux driver > and Virtual Machine Monitor (VMM) device. A guest-allocated shared > buffer is negotiated per-cpu through a few PCI MMIO registers, the VMM > device assigns a unique command for each per-cpu buffer. The guest > writes its memctl request in the per-cpu buffer, then writes the > corresponding command into the command register, calling into the VMM > device to perform the memctl request. > > The synchronous per-cpu shared buffer approach avoids the kick and busy > waiting that the guest would have to do with virtio virtqueue transport. > > We provide both kernel and userspace APIs > Kernel API > long memctl_vmm_call(__u64 func_code, __u64 addr, __u64 length, __u64 arg, >struct memctl_buf *buf); > > Kernel drivers can take advantage of the memctl calls to provide > paravirtualization of kernel stacks or page zeroing. > > User API > >From the userland, the memctl guest driver is controlled via ioctl(2) > call. It requires CAP_SYS_ADMIN. > > ioctl(fd, MEMCTL_IOCTL, union memctl_vmm *memctl_vmm); > > Guest userland applications can tag VMAs and guest hugepages, or advise > the host on how to handle sensitive guest pages. > > Supported function codes and their use cases: > MEMCTL_FREE/REMOVE/DONTNEED/PAGEOUT. For the guest. One can reduce the > struct page and page table lookup overhead by using hugepages backed by > smaller pages on the host. These memctl commands can allow for partial > freeing of private guest hugepages to save memory. They also allow > kernel memory, such as kernel stacks and task_structs to be > paravirtualized. > > MEMCTL_UNMERGEABLE is useful for security, when the VM does not want to > share its backing pages. > The same with MADV_DONTDUMP, so sensitive pages are not included in a > dump. > MLOCK/UNLOCK can advise the host that sensitive information is not > swapped out on the host. > > MEMCTL_MPROTECT_NONE/R/W/RW. For guest stacks backed by hugepages, stack > guard pages can be handled in the host and memory can be saved in the > hugepage. > > MEMCTL_SET_VMA_ANON_NAME is useful for observability and debugging how > guest memory is being mapped on the host. > > Sample program making use of MEMCTL_SET_VMA_ANON_NAME and > MEMCTL_DONTNEED: > https://github.com/Dummyc0m/memctl-set-anon-vma-name/tree/main > https://github.com/Dummyc0m/memctl-set-anon-vma-name/tree/dontneed > > The VMM implementation is being proposed for Cloud Hypervisor: > https://github.com/Dummyc0m/cloud-hypervisor/ > > Cloud Hypervisor issue: > https://github.com/cloud-hypervisor/cloud-hypervisor/issues/6318 > > Signed-off-by: Yuanchu Xie > --- > .../userspace-api/ioctl/ioctl-number.rst | 2 + > drivers/virt/Kconfig | 2 + > drivers/virt/Makefile | 1 + > drivers/virt/memctl/Kconfig | 10 + > drivers/virt/memctl/Makefile | 2 + > drivers/virt/memctl/memctl.c | 425 ++ > include/linux/memctl.h| 27 ++ > include/uapi/linux/memctl.h | 81 You are mixing your PCI driver in with the memctl core code, is that intentional? Will there never be another PCI device for this type of interface other than this one PCI device? And if so, why export anything, why isn't this all in one body of code? > 8 files changed, 550 insertions(+) > create mode 100644 drivers/virt/memctl/Kconfig > create mode 100644 drivers/virt/memctl/Makefile > create mode 100644 drivers/virt/memctl/memctl.c > create mode 100644 include/linux/memctl.h > create mode 100644 include/uapi/linux/memctl.h > > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst > b/Documentation/userspace-api/ioctl/ioctl-number.rst > index 457e16f06e04..789d1251c0be 100644 > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst > @@ -368,6 +368,8 @@ Code Seq#Include File >Comments > 0xCD 01 linux/reiserfs_fs.h > 0xCE 01-02 uapi/linux/cxl_mem.hComput
Re: [PATCH] Revert "tracing/trigger: Fix to return error if failed to alloc snapshot"
On Thu, Apr 18, 2024 at 06:58:06PM +0530, Siddh Raman Pant wrote:
> This reverts commit b5085b5ac1d96ea2a8a6240f869655176ce44197.
>
> The change has an incorrect assumption about the return value because
> in the current stable trees for versions 5.15 and before, the following
> commit responsible for making 0 a success value is not present:
> b8cc44a4d3c1 ("tracing: Remove logic for registering multiple event triggers
> at a time")
>
> The return value should be 0 on failure in the current tree, because in
> the functions event_trigger_callback() and event_enable_trigger_func(),
> we have:
>
> ret = cmd_ops->reg(glob, trigger_ops, trigger_data, file);
> /*
>* The above returns on success the # of functions enabled,
>* but if it didn't find any functions it returns zero.
>* Consider no functions a failure too.
>*/
> if (!ret) {
> ret = -ENOENT;
>
> Cc: sta...@kernel.org # 5.15, 5.10, 5.4, 4.19
> Signed-off-by: Siddh Raman Pant
> ---
> kernel/trace/trace_events_trigger.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
Now queued up everywhere, thanks.
greg k-h
Re: [PATCH] [v4] module: don't ignore sysfs_create_link() failures
On Mon, Apr 08, 2024 at 09:00:06AM -0700, Luis Chamberlain wrote:
> On Mon, Apr 08, 2024 at 10:05:58AM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The sysfs_create_link() return code is marked as __must_check, but the
> > module_add_driver() function tries hard to not care, by assigning the
> > return code to a variable. When building with 'make W=1', gcc still
> > warns because this variable is only assigned but not used:
> >
> > drivers/base/module.c: In function 'module_add_driver':
> > drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used
> > [-Wunused-but-set-variable]
> >
> > Rework the code to properly unwind and return the error code to the
> > caller. My reading of the original code was that it tries to
> > not fail when the links already exist, so keep ignoring -EEXIST
> > errors.
> >
> > Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
> > Reviewed-by: Greg Kroah-Hartman
>
> Reviewed-by: Luis Chamberlain
Oh right, I should apply this, sorry about that, will go do that now...
Re: [PATCH] [v3] module: don't ignore sysfs_create_link() failures
On Tue, Mar 26, 2024 at 03:57:18PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The sysfs_create_link() return code is marked as __must_check, but the
> module_add_driver() function tries hard to not care, by assigning the
> return code to a variable. When building with 'make W=1', gcc still
> warns because this variable is only assigned but not used:
>
> drivers/base/module.c: In function 'module_add_driver':
> drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used
> [-Wunused-but-set-variable]
>
> Rework the code to properly unwind and return the error code to the
> caller. My reading of the original code was that it tries to
> not fail when the links already exist, so keep ignoring -EEXIST
> errors.
>
> Cc: Luis Chamberlain
> Cc: linux-modu...@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
> See-also: 4a7fb6363f2d ("add __must_check to device management code")
> Signed-off-by: Arnd Bergmann
> ---
> v3: make error handling stricter, add unwinding,
> fix build fail with CONFIG_MODULES=n
> v2: rework to actually handle the error. I have not tested the
> error handling beyond build testing, so please review carefully.
> ---
> drivers/base/base.h | 9 ++---
> drivers/base/bus.c| 9 ++++-
> drivers/base/module.c | 42 +++---
> 3 files changed, 45 insertions(+), 15 deletions(-)
Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] [v2] module: don't ignore sysfs_create_link() failures
On Fri, Mar 22, 2024 at 06:39:11PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The sysfs_create_link() return code is marked as __must_check, but the
> module_add_driver() function tries hard to not care, by assigning the
> return code to a variable. When building with 'make W=1', gcc still
> warns because this variable is only assigned but not used:
>
> drivers/base/module.c: In function 'module_add_driver':
> drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used
> [-Wunused-but-set-variable]
>
> Rework the code to properly unwind and return the error code to the
> caller. My reading of the original code was that it tries to
> not fail when the links already exist, so keep ignoring -EEXIST
> errors.
>
> Cc: Luis Chamberlain
> Cc: linux-modu...@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
> See-also: 4a7fb6363f2d ("add __must_check to device management code")
> Signed-off-by: Arnd Bergmann
> ---
> v2: rework to actually handle the error. I have not tested the
> error handling beyond build testing, so please review carefully.
> ---
> drivers/base/base.h | 2 +-
> drivers/base/bus.c| 7 ++-
> drivers/base/module.c | 42 +++---
> 3 files changed, 38 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/base/base.h b/drivers/base/base.h
> index 0738ccad08b2..0e04bfe02943 100644
> --- a/drivers/base/base.h
> +++ b/drivers/base/base.h
> @@ -192,7 +192,7 @@ extern struct kset *devices_kset;
> void devices_kset_move_last(struct device *dev);
>
> #if defined(CONFIG_MODULES) && defined(CONFIG_SYSFS)
> -void module_add_driver(struct module *mod, struct device_driver *drv);
> +int module_add_driver(struct module *mod, struct device_driver *drv);
> void module_remove_driver(struct device_driver *drv);
> #else
> static inline void module_add_driver(struct module *mod,
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index daee55c9b2d9..7ef75b60d331 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -674,7 +674,12 @@ int bus_add_driver(struct device_driver *drv)
> if (error)
> goto out_del_list;
> }
> - module_add_driver(drv->owner, drv);
> + error = module_add_driver(drv->owner, drv);
> + if (error) {
> + printk(KERN_ERR "%s: failed to create module links for %s\n",
> + __func__, drv->name);
> + goto out_del_list;
Don't we need to walk back the driver_attach() call here if this fails?
> + }
>
> error = driver_create_file(drv, &driver_attr_uevent);
> if (error) {
> diff --git a/drivers/base/module.c b/drivers/base/module.c
> index 46ad4d636731..61282eaed670 100644
> --- a/drivers/base/module.c
> +++ b/drivers/base/module.c
> @@ -30,14 +30,14 @@ static void module_create_drivers_dir(struct
> module_kobject *mk)
> mutex_unlock(&drivers_dir_mutex);
> }
>
> -void module_add_driver(struct module *mod, struct device_driver *drv)
> +int module_add_driver(struct module *mod, struct device_driver *drv)
> {
> char *driver_name;
> - int no_warn;
> + int ret;
> struct module_kobject *mk = NULL;
>
> if (!drv)
> - return;
> + return 0;
>
> if (mod)
> mk = &mod->mkobj;
> @@ -56,17 +56,37 @@ void module_add_driver(struct module *mod, struct
> device_driver *drv)
> }
>
> if (!mk)
> - return;
> + return 0;
> +
> + ret = sysfs_create_link(&drv->p->kobj, &mk->kobj, "module");
> + if (ret && ret != -EEXIST)
Why would EEXIST happen here? How can this be called twice?
> + return ret;
>
> - /* Don't check return codes; these calls are idempotent */
> - no_warn = sysfs_create_link(&drv->p->kobj, &mk->kobj, "module");
> driver_name = make_driver_name(drv);
> - if (driver_name) {
> - module_create_drivers_dir(mk);
> - no_warn = sysfs_create_link(mk->drivers_dir, &drv->p->kobj,
> - driver_name);
> - kfree(driver_name);
> + if (!driver_name) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + module_create_drivers_dir(mk);
> + if (!mk->drivers_dir) {
> + ret = -EINVAL;
> + goto out;
> }
> +
> + ret = sysfs_create_link(mk->drivers_dir, &drv->p->kobj, driver_name);
> + if (ret && ret != -EEXIST)
> + goto out;
Same EEXIST question here.
thanks,
greg k-h
Re: [PATCH] module: silence warning about unused 'no_warn' variable
On Fri, Mar 22, 2024 at 02:20:05PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The sysfs_create_link() return code is marked as __must_check, but the
> module_add_driver() function tries hard to not care, by assigning the
> return code to a variable. When building with 'make W=1', gcc still
> warns because this variable is only assigned but not used:
>
> drivers/base/module.c: In function 'module_add_driver':
> drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used
> [-Wunused-but-set-variable]
>
> Add an explicit cast to void to prevent this check as well.
>
> Cc: Luis Chamberlain
> Cc: linux-modu...@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
> See-also: 4a7fb6363f2d ("add __must_check to device management code")
> Signed-off-by: Arnd Bergmann
> ---
> I'm not entirely sure what bug the __must_check on sysfs_create_link()
> is trying to prevent, or why the module loader code is allowed to
> ignore this. It would be nice to have an Ack from the sysfs maintainers
> on this.
No, let's fix this properly and unwind if we can't create the link. You
are pointing at something from 2006, so I guess we always thought "this
can not fail" and never did anything about it since then.
thanks,
greg k-h
Re: [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)
On Wed, Feb 07, 2024 at 12:20:00AM +0100, Luca Weiss wrote:
> On Tue Jan 2, 2024 at 2:53 PM CET, Greg Kroah-Hartman wrote:
> > On Tue, Jan 02, 2024 at 02:43:24PM +0100, Luca Weiss wrote:
> > > On Tue Jan 2, 2024 at 2:36 PM CET, Greg Kroah-Hartman wrote:
> > > > On Thu, Dec 21, 2023 at 02:45:26PM +0100, Luca Weiss wrote:
> > > > > On Thu Dec 21, 2023 at 1:53 PM CET, Konrad Dybcio wrote:
> > > > > > On 21.12.2023 11:34, Dmitry Baryshkov wrote:
> > > > > > > On Thu, 21 Dec 2023 at 09:33, Luca Weiss
> > > > > > > wrote:
> > > > > > >>
> > > > > > >> On Wed Dec 20, 2023 at 1:32 PM CET, Konrad Dybcio wrote:
> > > > > > >>> On 20.12.2023 11:02, Luca Weiss wrote:
> > > > > > >>>> This series adds all the necessary bits to enable USB-C role
> > > > > > >>>> switching,
> > > > > > >>>> charger and fuel gauge (all via pmic-glink) on Fairphone 5.
> > > > > > >>>>
> > > > > > >>>> One thing that could be made different is the pmic-glink
> > > > > > >>>> compatible.
> > > > > > >>>> I've chosen to use qcm6490 compatible for it and not sc7280
> > > > > > >>>> since
> > > > > > >>>> there's plenty of firmware variety on sc7280-based platforms
> > > > > > >>>> and they
> > > > > > >>>> might require different quirks in the future, so limit this
> > > > > > >>>> PDOS quirk
> > > > > > >>>> to just qcm6490 for now.
> > > > > > >>>>
> > > > > > >>>> If someone thinks it should be qcom,sc7280-pmic-glink, please
> > > > > > >>>> let me
> > > > > > >>>> know :)
> > > > > > >>> IMO it's best to continue using the "base soc" (which just so
> > > > > > >>> happened
> > > > > > >>> to fall onto sc7280 this time around) for all compatibles,
> > > > > > >>> unless the
> > > > > > >>> derivatives actually had changes
> > > > > > >>
> > > > > > >> Hi Konrad,
> > > > > > >>
> > > > > > >> I think at some point I asked Dmitry what he thought and he
> > > > > > >> mentioned
> > > > > > >> qcm6490. Even found the message again:
> > > > > > >>
> > > > > > >>> well, since it is a firmware thing, you might want to emphasise
> > > > > > >>> that.
> > > > > > >>> So from my POV qcm6490 makes more sense
> > > > > > >>
> > > > > > >> But yeah since it's likely that sc7280 firmware behaves the same
> > > > > > >> as
> > > > > > >> qcm6490 firmware it's probably okay to use sc7280 compatible,
> > > > > > >> worst case
> > > > > > >> we change it later :) I'll send a v2 with those changes.
> > > > > > >
> > > > > > > Worst case we end up with sc7280 which has yet another slightly
> > > > > > > different UCSI / PMIC GLINK implementation, but the compatible
> > > > > > > string
> > > > > > > is already taken.
> > > > > > > I still suppose that this should be a qcm6490-related string.
> > > > > > Right, let's keep qcm then
> > > > >
> > > > > Ack from my side also. Thanks for the feedback!
> > > >
> > > > This doesn't apply to my tree, where should it be going through?
> > >
> > > As far as I can see the dependency for the driver commit 1d103d6af241
> > > ("usb: typec: ucsi: fix UCSI on buggy Qualcomm devices") was applied to
> > > Bjorn's qcom tree, so 2/3 should also go there then.
> > >
> > > Patch 3/3 (arm64 dts) definitely also Bjorn's qcom tree.
> > >
> > > So that leaves patch 1/3 which Bjorn can probably pick up as well but
> > > looking at git log you also picked up some for that file in the past,
> > > dunno.
> >
> > Ok, for any remaining ones that want to be merged before 6.8-rc1 is out,
> > feel free to add my:
> >
> > Acked-by: Greg Kroah-Hartman
> >
> > If they don't get picked up by 6.8-rc1, feel free to rebase and send it
> > for me to take through my tree.
>
> Hi Greg,
>
> This applies cleanly on -next as of next-20240206 still.
>
> Could you please pick it up for v6.9? I can also send a v2 with only
> the two remaining patches (dts was applied to qcom by Bjorn already).
v2 with just the remaining patches would be great, thanks.
greg k-h
Re: [PATCH] device-dax: make dax_bus_type const
On Sun, Feb 04, 2024 at 01:07:11PM -0300, Ricardo B. Marliere wrote: > Now that the driver core can properly handle constant struct bus_type, > move the dax_bus_type variable to be a constant structure as well, > placing it into read-only memory which can not be modified at runtime. > > Cc: Greg Kroah-Hartman > Suggested-by: Greg Kroah-Hartman > Signed-off-by: Ricardo B. Marliere Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] nvdimm: make nvdimm_bus_type const
On Sun, Feb 04, 2024 at 05:20:07PM -0300, Ricardo B. Marliere wrote: > Now that the driver core can properly handle constant struct bus_type, > move the nvdimm_bus_type variable to be a constant structure as well, > placing it into read-only memory which can not be modified at runtime. > > Cc: Greg Kroah-Hartman > Suggested-by: Greg Kroah-Hartman > Signed-off-by: Ricardo B. Marliere Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] rpmsg: core: make rpmsg_bus const
On Sun, Feb 04, 2024 at 05:32:05PM -0300, Ricardo B. Marliere wrote: > Now that the driver core can properly handle constant struct bus_type, > move the rpmsg_bus variable to be a constant structure as well, > placing it into read-only memory which can not be modified at runtime. > > Cc: Greg Kroah-Hartman > Suggested-by: Greg Kroah-Hartman > Signed-off-by: Ricardo B. Marliere Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] vdpa: make vdpa_bus const
On Sun, Feb 04, 2024 at 05:50:45PM -0300, Ricardo B. Marliere wrote: > Now that the driver core can properly handle constant struct bus_type, > move the vdpa_bus variable to be a constant structure as well, > placing it into read-only memory which can not be modified at runtime. > > Cc: Greg Kroah-Hartman > Suggested-by: Greg Kroah-Hartman > Signed-off-by: Ricardo B. Marliere Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] virtio: make virtio_bus const
On Sun, Feb 04, 2024 at 05:52:51PM -0300, Ricardo B. Marliere wrote: > Now that the driver core can properly handle constant struct bus_type, > move the virtio_bus variable to be a constant structure as well, > placing it into read-only memory which can not be modified at runtime. > > Cc: Greg Kroah-Hartman > Suggested-by: Greg Kroah-Hartman > Signed-off-by: Ricardo B. Marliere Reviewed-by: Greg Kroah-Hartman
Re: [PATCH v2 0/5] PM: domains: Add helpers for multi PM domains to avoid open-coding
On Fri, Jan 26, 2024 at 05:12:12PM +0100, Ulf Hansson wrote: > On Fri, 5 Jan 2024 at 17:01, Ulf Hansson wrote: > > > > Updates in v2: > > - Ccing Daniel Baluta and Iuliana Prodan the NXP remoteproc patches > > to > > requests help with testing. > > - Fixed NULL pointer bug in patch1, pointed out by Nikunj. > > - Added some tested/reviewed-by tags. > > > > > > Attaching/detaching of a device to multiple PM domains has started to > > become a > > common operation for many drivers, typically during ->probe() and > > ->remove(). > > In most cases, this has lead to lots of boilerplate code in the drivers. > > > > This series adds a pair of helper functions to manage the attach/detach of a > > device to its multiple PM domains. Moreover, a couple of drivers have been > > converted to use the new helpers as a proof of concept. > > > > Note 1) > > The changes in the drivers have only been compile tested, while the helpers > > have been tested along with a couple of local dummy drivers that I have > > hacked > > up to model both genpd providers and genpd consumers. > > > > Note 2) > > I was struggling to make up mind if we should have a separate helper to > > attach > > all available power-domains described in DT, rather than providing "NULL" > > to the > > dev_pm_domain_attach_list(). I decided not to, but please let me know if you > > prefer the other option. > > > > Note 3) > > For OPP integration, as a follow up I am striving to make the > > dev_pm_opp_attach_genpd() redundant. Instead I think we should move towards > > using dev_pm_opp_set_config()->_opp_set_required_devs(), which would allow > > us to > > use the helpers that $subject series is adding. > > > > Kind regards > > Ulf Hansson > > Rafael, Greg, do have any objections to this series or would you be > okay that I queue this up via my pmdomain tree? I'll defer to Rafael here.
Re: [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)
On Tue, Jan 02, 2024 at 02:43:24PM +0100, Luca Weiss wrote:
> On Tue Jan 2, 2024 at 2:36 PM CET, Greg Kroah-Hartman wrote:
> > On Thu, Dec 21, 2023 at 02:45:26PM +0100, Luca Weiss wrote:
> > > On Thu Dec 21, 2023 at 1:53 PM CET, Konrad Dybcio wrote:
> > > > On 21.12.2023 11:34, Dmitry Baryshkov wrote:
> > > > > On Thu, 21 Dec 2023 at 09:33, Luca Weiss
> > > > > wrote:
> > > > >>
> > > > >> On Wed Dec 20, 2023 at 1:32 PM CET, Konrad Dybcio wrote:
> > > > >>> On 20.12.2023 11:02, Luca Weiss wrote:
> > > > >>>> This series adds all the necessary bits to enable USB-C role
> > > > >>>> switching,
> > > > >>>> charger and fuel gauge (all via pmic-glink) on Fairphone 5.
> > > > >>>>
> > > > >>>> One thing that could be made different is the pmic-glink
> > > > >>>> compatible.
> > > > >>>> I've chosen to use qcm6490 compatible for it and not sc7280 since
> > > > >>>> there's plenty of firmware variety on sc7280-based platforms and
> > > > >>>> they
> > > > >>>> might require different quirks in the future, so limit this PDOS
> > > > >>>> quirk
> > > > >>>> to just qcm6490 for now.
> > > > >>>>
> > > > >>>> If someone thinks it should be qcom,sc7280-pmic-glink, please let
> > > > >>>> me
> > > > >>>> know :)
> > > > >>> IMO it's best to continue using the "base soc" (which just so
> > > > >>> happened
> > > > >>> to fall onto sc7280 this time around) for all compatibles, unless
> > > > >>> the
> > > > >>> derivatives actually had changes
> > > > >>
> > > > >> Hi Konrad,
> > > > >>
> > > > >> I think at some point I asked Dmitry what he thought and he mentioned
> > > > >> qcm6490. Even found the message again:
> > > > >>
> > > > >>> well, since it is a firmware thing, you might want to emphasise
> > > > >>> that.
> > > > >>> So from my POV qcm6490 makes more sense
> > > > >>
> > > > >> But yeah since it's likely that sc7280 firmware behaves the same as
> > > > >> qcm6490 firmware it's probably okay to use sc7280 compatible, worst
> > > > >> case
> > > > >> we change it later :) I'll send a v2 with those changes.
> > > > >
> > > > > Worst case we end up with sc7280 which has yet another slightly
> > > > > different UCSI / PMIC GLINK implementation, but the compatible string
> > > > > is already taken.
> > > > > I still suppose that this should be a qcm6490-related string.
> > > > Right, let's keep qcm then
> > >
> > > Ack from my side also. Thanks for the feedback!
> >
> > This doesn't apply to my tree, where should it be going through?
>
> As far as I can see the dependency for the driver commit 1d103d6af241
> ("usb: typec: ucsi: fix UCSI on buggy Qualcomm devices") was applied to
> Bjorn's qcom tree, so 2/3 should also go there then.
>
> Patch 3/3 (arm64 dts) definitely also Bjorn's qcom tree.
>
> So that leaves patch 1/3 which Bjorn can probably pick up as well but
> looking at git log you also picked up some for that file in the past,
> dunno.
Ok, for any remaining ones that want to be merged before 6.8-rc1 is out,
feel free to add my:
Acked-by: Greg Kroah-Hartman
If they don't get picked up by 6.8-rc1, feel free to rebase and send it
for me to take through my tree.
thanks,
greg k-h
Re: [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)
On Thu, Dec 21, 2023 at 02:45:26PM +0100, Luca Weiss wrote: > On Thu Dec 21, 2023 at 1:53 PM CET, Konrad Dybcio wrote: > > On 21.12.2023 11:34, Dmitry Baryshkov wrote: > > > On Thu, 21 Dec 2023 at 09:33, Luca Weiss wrote: > > >> > > >> On Wed Dec 20, 2023 at 1:32 PM CET, Konrad Dybcio wrote: > > >>> On 20.12.2023 11:02, Luca Weiss wrote: > > This series adds all the necessary bits to enable USB-C role switching, > > charger and fuel gauge (all via pmic-glink) on Fairphone 5. > > > > One thing that could be made different is the pmic-glink compatible. > > I've chosen to use qcm6490 compatible for it and not sc7280 since > > there's plenty of firmware variety on sc7280-based platforms and they > > might require different quirks in the future, so limit this PDOS quirk > > to just qcm6490 for now. > > > > If someone thinks it should be qcom,sc7280-pmic-glink, please let me > > know :) > > >>> IMO it's best to continue using the "base soc" (which just so happened > > >>> to fall onto sc7280 this time around) for all compatibles, unless the > > >>> derivatives actually had changes > > >> > > >> Hi Konrad, > > >> > > >> I think at some point I asked Dmitry what he thought and he mentioned > > >> qcm6490. Even found the message again: > > >> > > >>> well, since it is a firmware thing, you might want to emphasise that. > > >>> So from my POV qcm6490 makes more sense > > >> > > >> But yeah since it's likely that sc7280 firmware behaves the same as > > >> qcm6490 firmware it's probably okay to use sc7280 compatible, worst case > > >> we change it later :) I'll send a v2 with those changes. > > > > > > Worst case we end up with sc7280 which has yet another slightly > > > different UCSI / PMIC GLINK implementation, but the compatible string > > > is already taken. > > > I still suppose that this should be a qcm6490-related string. > > Right, let's keep qcm then > > Ack from my side also. Thanks for the feedback! This doesn't apply to my tree, where should it be going through? thanks, greg k-h
Re: [PATCH v6 2/4] dax/bus: Use guard(device) in sysfs attribute helpers
On Thu, Dec 14, 2023 at 10:25:27PM -0700, Vishal Verma wrote:
> Use the guard(device) macro to lock a 'struct device', and unlock it
> automatically when going out of scope using Scope Based Resource
> Management semantics. A lot of the sysfs attribute writes in
> drivers/dax/bus.c benefit from a cleanup using these, so change these
> where applicable.
Wait, why are you needing to call device_lock() at all here? Why is dax
special in needing this when no other subsystem requires it?
>
> Cc: Joao Martins
> Cc: Dan Williams
> Signed-off-by: Vishal Verma
> ---
> drivers/dax/bus.c | 143
> ++
> 1 file changed, 59 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 1ff1ab5fa105..6226de131d17 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -294,13 +294,10 @@ static ssize_t available_size_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> struct dax_region *dax_region = dev_get_drvdata(dev);
> - unsigned long long size;
>
> - device_lock(dev);
> - size = dax_region_avail_size(dax_region);
> - device_unlock(dev);
> + guard(device)(dev);
You have a valid device here, why are you locking it? How can it go
away? And if it can, shouldn't you have a local lock for it, and not
abuse the driver core lock?
>
> - return sprintf(buf, "%llu\n", size);
> + return sprintf(buf, "%llu\n", dax_region_avail_size(dax_region));
sysfs_emit() everywhere please.
But again, the issue is "why do you need a lock"?
thanks,
greg k-h
Re: [PATCH v5 4/4] dax: add a sysfs knob to control memmap_on_memory behavior
On Thu, Dec 14, 2023 at 12:37:57AM -0700, Vishal Verma wrote:
> +static ssize_t memmap_on_memory_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct dev_dax *dev_dax = to_dev_dax(dev);
> +
> + return sprintf(buf, "%d\n", dev_dax->memmap_on_memory);
checkpatch should have noticed that this should be sysfs_emit(), right?
If not, please make the change anyway.
> diff --git a/Documentation/ABI/testing/sysfs-bus-dax
> b/Documentation/ABI/testing/sysfs-bus-dax
> index 6359f7bc9bf4..40d9965733b2 100644
> --- a/Documentation/ABI/testing/sysfs-bus-dax
> +++ b/Documentation/ABI/testing/sysfs-bus-dax
> @@ -134,3 +134,20 @@ KernelVersion: v5.1
> Contact: nvd...@lists.linux.dev
> Description:
> (RO) The id attribute indicates the region id of a dax region.
> +
> +What:/sys/bus/dax/devices/daxX.Y/memmap_on_memory
> +Date:October, 2023
It's not October anymore :)
thanks,
greg k-h
Re: [ANNOUNCE] 5.10.201-rt98
On Wed, Nov 22, 2023 at 10:36:23AM -0300, Luis Claudio R. Goncalves wrote: > On Tue, Nov 21, 2023 at 10:01:25PM -0300, Luis Claudio R. Goncalves wrote: > > Hello RT-list! > > > > I'm pleased to announce the 5.10.201-rt98 stable release. > > > > This release is just an update to the new stable 5.10.201 > > version and no RT changes have been made. > > > > You can get this release via the git tree at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > > branch: v5.10-rt > > Head SHA1: 3a93f0a0d49dd0db4c6876ca9a7369350e64320e > > Greg KH, > > While testing v5.10.201-rt98 I stumbled over this warning: > > [ 1000.312397] run blktests nvme/005 at 2023-11-21 21:46:30 > ... > [ 1000.500478] workqueue: WQ_MEM_RECLAIM nvmet_tcp_wq:nvmet_tcp_io_work > [nvmet_tcp] is flushing !WQ_MEM_RECLAIM events:0x0 > [ 1000.500490] WARNING: CPU: 0 PID: 6 at kernel/workqueue.c:2620 > check_flush_dependency+0x11f/0x140 > > That seems to be fixed by: > > 533d2e8b4d5e4 nvmet-tcp: fix lockdep complaint on nvmet_tcp_wq flush > during queue teardown > (and depending on what else is backported) > ddd2b8de9f85b nvmet: fix workqueue MEM_RECLAIM flushing dependency > > Is this something that can be added to your v5.10 queue or should I carry > this fix on v5.10-rt in the meantime? That's odd, as this commit is already in the 5.10.138 release, so how can we apply it again? confused, greg k-h
Re: [REGRESSION] USB ports do not work after suspend/resume cycle with v6.6.2
On Fri, Nov 24, 2023 at 01:59:24PM +0100, Vlastimil Babka wrote: > +Cc workflows > > On 11/24/23 12:43, Greg Kroah-Hartman wrote: > > On Thu, Nov 23, 2023 at 07:20:46PM +0100, Oleksandr Natalenko wrote: > >> Hello. > >> > >> Since v6.6.2 kernel release I'm experiencing a regression with regard > >> to USB ports behaviour after a suspend/resume cycle. > >> > >> If a USB port is empty before suspending, after resuming the machine > >> the port doesn't work. After a device insertion there's no reaction in > >> the kernel log whatsoever, although I do see that the device gets > >> powered up physically. If the machine is suspended with a device > >> inserted into the USB port, the port works fine after resume. > >> > >> This is an AMD-based machine with hci version 0x110 reported. As per > >> the changelog between v6.6.1 and v6.6.2, 603 commits were backported > >> into v6.6.2, and one of the commits was as follows: > >> > >> $ git log --oneline v6.6.1..v6.6.2 -- drivers/usb/host/xhci-pci.c > >> 14a51fa544225 xhci: Loosen RPM as default policy to cover for AMD xHC > >> 1.1 > >> > >> It seems that this commit explicitly enables runtime PM specifically > >> for my platform. As per dmesg: > >> > >> v6.6.1: quirks 0x0410 v6.6.2: quirks 0x00020410 > >> > >> Here, bit 33 gets set, which, as expected, corresponds to: > >> > >> drivers/usb/host/xhci.h 1895:#define XHCI_DEFAULT_PM_RUNTIME_ALLOW > >> BIT_ULL(33) > >> > >> This commit is backported from the upstream commit 4baf12181509, which > >> is one of 16 commits of the following series named "xhci features": > >> > >> https://lore.kernel.org/all/20231019102924.2797346-1-mathias.ny...@linux.intel.com/ > >> > >> It appears that there was another commit in this series, also from > >> Basavaraj (in Cc), a5d6264b638e, which was not picked for v6.6.2, but > >> which stated the following: > >> > >> Use the low-power states of the underlying platform to enable runtime > >> PM. If the platform doesn't support runtime D3, then enabling default > >> RPM will result in the controller malfunctioning, as in the case of > >> hotplug devices not being detected because of a failed interrupt > >> generation. > >> > >> It felt like this was exactly my case. So, I've conducted two tests: > >> > >> 1. Reverted 14a51fa544225 from v6.6.2. With this revert the USB ports > >> started to work fine, just as they did in v6.6.1. 2. Left 14a51fa544225 > >> in place, but also applied upstream a5d6264b638e on top of v6.6.2. With > >> this patch added the USB ports also work after a suspend/resume cycle. > >> > >> This runtime PM enablement did also impact my AX200 Bluetooth device, > >> resulting in long delays before headphones/speaker can connect, but > >> I've solved this with btusb.enable_autosuspend=N. I think this has > >> nothing to do with the original issue, and I'm OK with this workaround > >> unless someone has got a different idea. > >> > >> With that, please consider either reverting 14a51fa544225 from the > >> stable kernel, or applying a5d6264b638e in addition to it. Given the > >> mainline kernel has got both of them, I'm in favour of applying > >> additional commit to the stable kernel. > > > > I've applied this other commit as well to all of the affected branches, > > thanks for letting us know. > > > >> I'm also Cc'ing all the people from our Mastodon discussion where I > >> initially complained about the issue as well as about stable kernel > >> branch stability: > >> > >> https://activitypub.natalenko.name/@oleksandr/statuses/01HFRXBYWMXF9G4KYPE3XHH0S8 > >> > >> I'm not going to expand more on that in this email, especially given > >> Greg indicated he read the conversation, but I'm open to continuing > >> this discussion as I still think that current workflow brings visible > >> issues to ordinary users, and hence some adjustments should be made. > > > > What type of adjustments exactly? Testing on wide ranges of systems is > > pretty hard, and this patch explicitly was set to be backported when it > > hit Linus's tree, > > Are you sure about that "explicitly was set to be backported" part? > According to Documentation/process/stable-kernel-ru
Re: [PATCH 04/10] staging: ks7010: remove unused ioctl handler
On Mon, Oct 09, 2023 at 04:19:02PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > The ndo_do_ioctl function has no actual callers, and doesn't do much here, > so just remove it entirely as preparation for removing the callback pointer > from net_device_ops. > > Signed-off-by: Arnd Bergmann Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 05/10] staging: rtl8192: remove unused legacy ioctl handlers
On Mon, Oct 09, 2023 at 04:19:03PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > The .ndo_do_ioctl functions are never called, and can just be removed, > especially since this is a staging driver. > > Signed-off-by: Arnd Bergmann > --- > drivers/staging/rtl8192u/ieee80211/dot11d.c | 41 -- > drivers/staging/rtl8192u/ieee80211/dot11d.h | 2 - > .../staging/rtl8192u/ieee80211/ieee80211.h| 12 - > .../rtl8192u/ieee80211/ieee80211_softmac.c| 563 -- > drivers/staging/rtl8192u/r8192U.h | 2 - > drivers/staging/rtl8192u/r8192U_core.c| 109 > 6 files changed, 729 deletions(-) Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 07/10] staging: rtl8723bs: remove dead code
On Mon, Oct 09, 2023 at 04:19:05PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > The .ndo_do_ioctl functions are never called, so the three implementation here > is useless but only works as a way to identify the device in the notifiers, > which can really be removed as well. > > Looking through the exported functions, I found a bunch more that have > no callers, so just drop all of those. > > Signed-off-by: Arnd Bergmann Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 06/10] staging: rtl8712: remove unused legacy ioctl handlers
On Mon, Oct 09, 2023 at 04:19:04PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > The .ndo_do_ioctl functions are never called, and can just be removed, > especially since this is a staging driver. > > Signed-off-by: Arnd Bergmann > --- > drivers/staging/rtl8712/os_intfs.c| 1 - > drivers/staging/rtl8712/osdep_intf.h | 2 - > drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 124 -- > 3 files changed, 127 deletions(-) Reviewed-by: Greg Kroah-Hartman
[PATCH] testing: nvdimm: make struct class structures constant
Now that the driver core allows for struct class to be in read-only
memory, we should make all 'class' structures declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at runtime.
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Signed-off-by: Greg Kroah-Hartman
---
tools/testing/nvdimm/test/ndtest.c | 17 +
tools/testing/nvdimm/test/nfit.c | 14 +++---
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/tools/testing/nvdimm/test/ndtest.c
b/tools/testing/nvdimm/test/ndtest.c
index 3eba10c1e3e8..fd26189d53be 100644
--- a/tools/testing/nvdimm/test/ndtest.c
+++ b/tools/testing/nvdimm/test/ndtest.c
@@ -38,7 +38,11 @@ enum {
static DEFINE_SPINLOCK(ndtest_lock);
static struct ndtest_priv *instances[NUM_INSTANCES];
-static struct class *ndtest_dimm_class;
+
+static const struct class ndtest_dimm_class = {
+ .name = "nfit_test_dimm",
+};
+
static struct gen_pool *ndtest_pool;
static struct ndtest_dimm dimm_group1[] = {
@@ -737,7 +741,7 @@ static int ndtest_dimm_register(struct ndtest_priv *priv,
return -ENXIO;
}
- dimm->dev = device_create_with_groups(ndtest_dimm_class,
+ dimm->dev = device_create_with_groups(&ndtest_dimm_class,
&priv->pdev.dev,
0, dimm, dimm_attribute_groups,
"test_dimm%d", id);
@@ -906,8 +910,7 @@ static void cleanup_devices(void)
gen_pool_destroy(ndtest_pool);
- if (ndtest_dimm_class)
- class_destroy(ndtest_dimm_class);
+ class_unregister(&ndtest_dimm_class);
}
static __init int ndtest_init(void)
@@ -921,11 +924,9 @@ static __init int ndtest_init(void)
nfit_test_setup(ndtest_resource_lookup, NULL);
- ndtest_dimm_class = class_create("nfit_test_dimm");
- if (IS_ERR(ndtest_dimm_class)) {
- rc = PTR_ERR(ndtest_dimm_class);
+ rc = class_regster(&ndtest_dimm_class);
+ if (rc)
goto err_register;
- }
ndtest_pool = gen_pool_create(ilog2(SZ_4M), NUMA_NO_NODE);
if (!ndtest_pool) {
diff --git a/tools/testing/nvdimm/test/nfit.c b/tools/testing/nvdimm/test/nfit.c
index 005043bd9623..a61df347a33d 100644
--- a/tools/testing/nvdimm/test/nfit.c
+++ b/tools/testing/nvdimm/test/nfit.c
@@ -1712,7 +1712,9 @@ static void put_dimms(void *data)
device_unregister(t->dimm_dev[i]);
}
-static struct class *nfit_test_dimm;
+static const struct class nfit_test_dimm = {
+ .name = "nfit_test_dimm",
+};
static int dimm_name_to_id(struct device *dev)
{
@@ -1830,7 +1832,7 @@ static int nfit_test_dimm_init(struct nfit_test *t)
if (devm_add_action_or_reset(&t->pdev.dev, put_dimms, t))
return -ENOMEM;
for (i = 0; i < t->num_dcr; i++) {
- t->dimm_dev[i] = device_create_with_groups(nfit_test_dimm,
+ t->dimm_dev[i] = device_create_with_groups(&nfit_test_dimm,
&t->pdev.dev, 0, NULL,
nfit_test_dimm_attribute_groups,
"test_dimm%d", i + t->dcr_idx);
@@ -3276,11 +3278,9 @@ static __init int nfit_test_init(void)
if (!nfit_wq)
return -ENOMEM;
- nfit_test_dimm = class_create("nfit_test_dimm");
- if (IS_ERR(nfit_test_dimm)) {
- rc = PTR_ERR(nfit_test_dimm);
+ rc = class_register(&nfit_test_dimm);
+ if (rc)
goto err_register;
- }
nfit_pool = gen_pool_create(ilog2(SZ_4M), NUMA_NO_NODE);
if (!nfit_pool) {
@@ -3377,7 +3377,7 @@ static __exit void nfit_test_exit(void)
for (i = 0; i < NUM_NFITS; i++)
put_device(&instances[i]->pdev.dev);
- class_destroy(nfit_test_dimm);
+ class_unregister(&nfit_test_dimm);
}
module_init(nfit_test_init);
--
2.42.0
[PATCH] net: appletalk: remove cops support
The COPS Appletalk support is very old, never said to actually work properly, and the firmware code for the devices are under a very suspect license. Remove it all to clear up the license issue, if it is still needed and actually used by anyone, we can add it back later once the license is cleared up. Reported-by: Prarit Bhargava Cc: Christoph Hellwig Cc: Vitaly Kuznetsov Cc: jsch...@samba.org Signed-off-by: Greg Kroah-Hartman --- .../device_drivers/appletalk/cops.rst | 80 -- .../device_drivers/appletalk/index.rst| 18 - .../networking/device_drivers/index.rst |1 - drivers/net/Space.c |6 - drivers/net/appletalk/Kconfig | 30 - drivers/net/appletalk/Makefile|1 - drivers/net/appletalk/cops.c | 1005 - drivers/net/appletalk/cops.h | 61 - drivers/net/appletalk/cops_ffdrv.h| 532 - drivers/net/appletalk/cops_ltdrv.h| 241 include/net/Space.h |1 - 11 files changed, 1976 deletions(-) delete mode 100644 Documentation/networking/device_drivers/appletalk/cops.rst delete mode 100644 Documentation/networking/device_drivers/appletalk/index.rst delete mode 100644 drivers/net/appletalk/cops.c delete mode 100644 drivers/net/appletalk/cops.h delete mode 100644 drivers/net/appletalk/cops_ffdrv.h delete mode 100644 drivers/net/appletalk/cops_ltdrv.h diff --git a/Documentation/networking/device_drivers/appletalk/cops.rst b/Documentation/networking/device_drivers/appletalk/cops.rst deleted file mode 100644 index 964ba80599a9.. --- a/Documentation/networking/device_drivers/appletalk/cops.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - - -The COPS LocalTalk Linux driver (cops.c) - - -By Jay Schulist - -This driver has two modes and they are: Dayna mode and Tangent mode. -Each mode corresponds with the type of card. It has been found -that there are 2 main types of cards and all other cards are -the same and just have different names or only have minor differences -such as more IO ports. As this driver is tested it will -become more clear exactly what cards are supported. - -Right now these cards are known to work with the COPS driver. The -LT-200 cards work in a somewhat more limited capacity than the -DL200 cards, which work very well and are in use by many people. - -TANGENT driver mode: - - Tangent ATB-II, Novell NL-1000, Daystar Digital LT-200 - -DAYNA driver mode: - - Dayna DL2000/DaynaTalk PC (Half Length), COPS LT-95, - - Farallon PhoneNET PC III, Farallon PhoneNET PC II - -Other cards possibly supported mode unknown though: - - Dayna DL2000 (Full length) - -The COPS driver defaults to using Dayna mode. To change the driver's -mode if you built a driver with dual support use board_type=1 or -board_type=2 for Dayna or Tangent with insmod. - -Operation/loading of the driver -=== - -Use modprobe like this:/sbin/modprobe cops.o (IO #) (IRQ #) -If you do not specify any options the driver will try and use the IO = 0x240, -IRQ = 5. As of right now I would only use IRQ 5 for the card, if autoprobing. - -To load multiple COPS driver Localtalk cards you can do one of the following:: - - insmod cops io=0x240 irq=5 - insmod -o cops2 cops io=0x260 irq=3 - -Or in lilo.conf put something like this:: - - append="ether=5,0x240,lt0 ether=3,0x260,lt1" - -Then bring up the interface with ifconfig. It will look something like this:: - - lt0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-F7-00-00-00-00-00-00-00-00 - inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 - UP BROADCAST RUNNING NOARP MULTICAST MTU:600 Metric:1 - RX packets:0 errors:0 dropped:0 overruns:0 frame:0 - TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0 - -Netatalk Configuration -== - -You will need to configure atalkd with something like the following to make -it work with the cops.c driver. - -* For single LTalk card use:: - -dummy -seed -phase 2 -net 2000 -addr 2000.10 -zone "1033" -lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033" - -* For multiple cards, Ethernet and LocalTalk:: - -eth0 -seed -phase 2 -net 3000 -addr 3000.20 -zone "1033" -lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033" - -* For multiple LocalTalk cards, and an Ethernet card. - -* Order seems to matter here, Ethernet last:: - -lt0 -seed -phase 1 -net 1000 -addr 1000.10 -zone "LocalTalk1" -lt1 -seed -phase 1 -net 2000 -addr 2000.20 -zone "LocalTalk2" -eth0 -seed -phase 2 -net 3000 -addr 3000.30 -zone "EtherTalk" diff --git a/Documentation/networking/de
Re: [PATCH v3 2/8] cxl/acpi: Add root device lockdep validation
On Thu, Apr 21, 2022 at 08:33:18AM -0700, Dan Williams wrote: > The CXL "root" device, ACPI0017, is an attach point for coordinating > platform level CXL resources and is the parent device for a CXL port > topology tree. As such it has distinct locking rules relative to other > CXL subsystem objects, but because it is an ACPI device the lock class > is established well before it is given to the cxl_acpi driver. > > However, the lockdep API does support changing the lock class "live" for > situations like this. Add a device_lock_set_class() helper that a driver > can use in ->probe() to set a custom lock class, and > device_lock_reset_class() to return to the default "no validate" class > before the custom lock class key goes out of scope after ->remove(). > > Note the helpers are all macros to support dead code elimination in the > CONFIG_PROVE_LOCKING=n case. > > Suggested-by: Peter Zijlstra > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Cc: Ingo Molnar > Cc: Will Deacon > Cc: Waiman Long > Cc: Boqun Feng > Cc: Alison Schofield > Cc: Vishal Verma > Cc: Ira Weiny > Cc: Ben Widawsky > Cc: Jonathan Cameron > Signed-off-by: Dan Williams > --- > drivers/cxl/acpi.c | 15 +++ > include/linux/device.h | 25 + > 2 files changed, 40 insertions(+) Much simpler, great work. Reviewed-by: Greg Kroah-Hartman
Re: [PATCH v3 7/8] device-core: Kill the lockdep_mutex
On Thu, Apr 21, 2022 at 08:33:45AM -0700, Dan Williams wrote: > Per Peter [1], the lockdep API has native support for all the use cases > lockdep_mutex was attempting to enable. Now that all lockdep_mutex users > have been converted to those APIs, drop this lock. > > Link: > https://lore.kernel.org/r/ylf0dewci8myl...@hirez.programming.kicks-ass.net [1] > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Suggested-by: Peter Zijlstra > Signed-off-by: Dan Williams YES! Acked-by: Greg Kroah-Hartman Nice work.
Re: Re: [syzbot] INFO: rcu detected stall in tx
On Mon, Apr 19, 2021 at 08:56:19PM +, Guido Kiener wrote: > Hi all, > > The error is in usbtmc_interrupt(struct urb *urb) since five years. The > status code EPROTO is not handled correctly. > It's not a showstopper, but we should fix it and check the status code > according to usbtmc_read_bulk_cb() or > usb_skeleton.c. > @Dave: Do you have time? Otherwise I can do it. > @Greg: Is it urgent? No idea, but patches for known problems are always good to get completed as soon as possible :) thanks, greg k-h
Re: [PATCH 1/2] Revert "USB: serial: ch341: add new Product ID for CH341A"
On Mon, Apr 19, 2021 at 09:25:19PM -0500, Frank Zago wrote: > From: frank zago > > The 0x5512 USB PID is for the I2C/GPIO/SPI interfaces. UART is still > present but only the TX and RX pins are available; DTS, DTR, ... are > used for other things. Remove the PID, and let a I2C driver bind to > it. > > Existing CH341 boards usually have physical jumpers to switch between > the 3 modes. > > This reverts commit 46ee4abb10a07bd8f8ce910ee6b4ae6a947d7f63. > > Signed-off-by: Frank Zago > Signed-off-by: frank zago Why are you signing off twice?
Re: [PATCH 5.10 043/103] net: tipc: Fix spelling errors in net/tipc module
On Mon, Apr 19, 2021 at 11:32:47PM +0200, Pavel Machek wrote: > Hi! > > > [ Upstream commit a79ace4b312953c5835fafb12adc3cb6878b26bd ] > > > > These patches fix a series of spelling errors in net/tipc module. > > This should not be in -stable, it just cleans up comments. Agreed, now dropped, thanks. greg k-h
Re: [PATCH 5.10 042/103] net/rds: Avoid potential use after free in rds_send_remove_from_sock
On Mon, Apr 19, 2021 at 11:29:30PM +0200, Pavel Machek wrote: > Hi! > > > [ Upstream commit 0c85a7e87465f2d4cbc768e245f4f45b2f299b05 ] > > > > In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource > > is freed and later under spinlock, causing potential use-after-free. > > Set the free pointer to NULL to avoid undefined behavior. > > This patch is crazy. Take a look at Message-ID: > <20210419084953.GA28564@amd>. Or just look at the patch :-). You are correct, everything submitted from this author and domain recently was done as a "research project" to see if they could mess with kernel maintainers and slip in pointless changes to the kernel. Not acceptable at all... greg k-h
Re: [PATCH 5.10 042/103] net/rds: Avoid potential use after free in rds_send_remove_from_sock
On Mon, Apr 19, 2021 at 03:05:53PM +0200, Greg Kroah-Hartman wrote: > From: Aditya Pakki > > [ Upstream commit 0c85a7e87465f2d4cbc768e245f4f45b2f299b05 ] > > In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource > is freed and later under spinlock, causing potential use-after-free. > Set the free pointer to NULL to avoid undefined behavior. > > Signed-off-by: Aditya Pakki > Acked-by: Santosh Shilimkar > Signed-off-by: David S. Miller > Signed-off-by: Sasha Levin > --- > net/rds/message.c | 1 + > net/rds/send.c| 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/net/rds/message.c b/net/rds/message.c > index 799034e0f513..4fc66ff0f1ec 100644 > --- a/net/rds/message.c > +++ b/net/rds/message.c > @@ -180,6 +180,7 @@ void rds_message_put(struct rds_message *rm) > rds_message_purge(rm); > > kfree(rm); > + rm = NULL; > } > } > EXPORT_SYMBOL_GPL(rds_message_put); > diff --git a/net/rds/send.c b/net/rds/send.c > index 985d0b7713ac..fe5264b9d4b3 100644 > --- a/net/rds/send.c > +++ b/net/rds/send.c > @@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head > *messages, int status) > unlock_and_drop: > spin_unlock_irqrestore(&rm->m_rs_lock, flags); > rds_message_put(rm); > - if (was_on_sock) > + if (was_on_sock && rm) > rds_message_put(rm); > } > > -- > 2.30.2 > > > Ah crap, I will go drop this stuff. I also will strongly recommend that all maintainers blacklist umn.edu patches at this point in time, as it is obvious that a professor there is operating a sociological experiment on Linux kernel maintainers and is wasting our time. This is not ok. greg k-h
Re: [PATCH 00/13] [RFC] Rust support
On Mon, Apr 19, 2021 at 05:24:33PM -0700, Nick Desaulniers wrote: > On Fri, Apr 16, 2021 at 10:39 AM Willy Tarreau wrote: > > > > resources usage, I'm really not convinced at all it's suited for > > low-level development. I understand the interest of the experiment > > to help the language evolve into that direction, but I fear that > > the kernel will soon be as bloated and insecure as a browser, and > > that's really not to please me. > > Dunno, I don't think the introduction of Rust made Firefox _more_ insecure. > https://wiki.mozilla.org/Oxidation#Within_Firefox > > I pray no executives ever see Dmitry Vyukov's 2019 Linux Plumbers Conf > talk "Reflections on kernel quality, development process and testing." > https://www.youtube.com/watch?v=iAfrrNdl2f4 > or his 2018 Linux Security Summit talk "Syzbot and the Tale of > Thousand Kernel Bugs" https://www.youtube.com/watch?v=qrBVXxZDVQY > (and they're just fuzzing the syscall interface and USB devices. > Imagine once folks can more easily craft malformed bluetooth and wifi > packets.) > > I'd imagine the first term that comes to mind for them might be > "liability." They are quite sensitive to these vulnerabilities with > silly names, logos, and websites. There are many of us that believe > an incremental approach of introducing a memory safe language to our > existing infrastructure at the very least to attempt to improve the > quality of drivers for those that choose to use such tools is a better > approach. I would LOVE it if some "executives" would see the above presentations, because then they would maybe actually fund developers to fix bugs and maintain the kernel code, instead of only allowing them to add new features. Seriously, that's the real problem, that Dmitry's work has exposed, the lack of people allowed to do this type of bugfixing and maintenance on company time, for something that the company relies on, is a huge issue. "executives" feel that they are willing to fund the initial work and then "throw it over the wall to the community" once it is merged, and then they can forget about it as "the community" will maintain it for them for free. And that's a lie, as Dmitry's work shows. The world creates new use cases and testing ability all the time, which exposes bugs that have been around in old code. Once the bugs are fixed in that layer of code, the next layer down can finally be tested and then look, more corner cases of issues. Rewriting the kernel in another language is not going to fix the majority of the issues that fuzzing finds here automagically, as that work has exposed us to things like fault-injection and malicious USB packets that no language would have saved us from "automatically". All of those code paths deal with "unsafe" data that doesn't magically become "safe" because we switch languages. And over time, what we have determined is "safe" has changed! People forget that only a few years ago have we decided that the kernel now has to protect userspace programs from malicious hardware. That's a major shift in thinking, now data that we used to blindly trust can not be trusted at all. And "executives" want us to fix all of those issues for free, when really it's a major design shift for loads of kernel subsystems to handle this new threat model. So yes, please spread that talk around. Maybe then will we actually get funding and support to FIX the bugs that those tools test. Right now, the primary fixer of those findings are _INTERNS_ as that's all companies are willing to fund to fix this type of thing. And don't get me started on the inability for "executives" to fund other parts of Linux that they rely on, because they want "other companies" to do it instead. The tragedy-of-the-commons is a real threat to Linux, and always has been... thanks, greg k-h
[PATCH 5.4 22/73] ASoC: fsl_esai: Fix TDM slot setup for I2S mode
From: Alexander Shiyan [ Upstream commit e7a48c710defa0e0fef54d42b7d9e4ab596e2761 ] When using the driver in I2S TDM mode, the fsl_esai_startup() function rewrites the number of slots previously set by the fsl_esai_set_dai_tdm_slot() function to 2. To fix this, let's use the saved slot count value or, if TDM is not used and the number of slots is not set, the driver will use the default value (2), which is set by fsl_esai_probe(). Signed-off-by: Alexander Shiyan Acked-by: Nicolin Chen Link: https://lore.kernel.org/r/20210402081405.9892-1-shc_w...@mail.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/fsl/fsl_esai.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index 84290be778f0..33ade79fa032 100644 --- a/sound/soc/fsl/fsl_esai.c +++ b/sound/soc/fsl/fsl_esai.c @@ -494,11 +494,13 @@ static int fsl_esai_startup(struct snd_pcm_substream *substream, ESAI_SAICR_SYNC, esai_priv->synchronous ? ESAI_SAICR_SYNC : 0); - /* Set a default slot number -- 2 */ + /* Set slots count */ regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR, - ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(2)); + ESAI_xCCR_xDC_MASK, + ESAI_xCCR_xDC(esai_priv->slots)); regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR, - ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(2)); + ESAI_xCCR_xDC_MASK, + ESAI_xCCR_xDC(esai_priv->slots)); } return 0; -- 2.30.2
[PATCH 5.4 30/73] net: ieee802154: stop dump llsec devkeys for monitors
From: Alexander Aring
[ Upstream commit 080d1a57a94d93e70f84b7a360baa351388c574f ]
This patch stops dumping llsec devkeys for monitors which we don't support
yet. Otherwise we will access llsec mib which isn't initialized for
monitors.
Signed-off-by: Alexander Aring
Link: https://lore.kernel.org/r/20210405003054.256017-10-aahri...@redhat.com
Signed-off-by: Stefan Schmidt
Signed-off-by: Sasha Levin
---
net/ieee802154/nl802154.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 4f6777193029..66785e1eb559 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1874,6 +1874,11 @@ nl802154_dump_llsec_devkey(struct sk_buff *skb, struct
netlink_callback *cb)
if (err)
return err;
+ if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) {
+ err = skb->len;
+ goto out_err;
+ }
+
if (!wpan_dev->netdev) {
err = -EINVAL;
goto out_err;
--
2.30.2
[PATCH 5.4 60/73] ibmvnic: avoid calling napi_disable() twice
From: Lijun Pan
commit 0775ebc4cf8554bdcd2c212669a0868ab68df5c0 upstream.
__ibmvnic_open calls napi_disable without checking whether NAPI polling
has already been disabled or not. This could cause napi_disable
being called twice, which could generate deadlock. For example,
the first napi_disable will spin until NAPI_STATE_SCHED is cleared
by napi_complete_done, then set it again.
When napi_disable is called the second time, it will loop infinitely
because no dev->poll will be running to clear NAPI_STATE_SCHED.
To prevent above scenario from happening, call ibmvnic_napi_disable()
which checks if napi is disabled or not before calling napi_disable.
Fixes: bfc32f297337 ("ibmvnic: Move resource initialization to its own routine")
Suggested-by: Thomas Falcon
Signed-off-by: Lijun Pan
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/ibm/ibmvnic.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1081,8 +1081,7 @@ static int __ibmvnic_open(struct net_dev
rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_UP);
if (rc) {
- for (i = 0; i < adapter->req_rx_queues; i++)
- napi_disable(&adapter->napi[i]);
+ ibmvnic_napi_disable(adapter);
release_resources(adapter);
return rc;
}
[PATCH 5.4 68/73] r8169: fix performance regression related to PCIe max read request size
From: Heiner Kallweit
[ Upstream commit 21b5f672fb2eb1366dedc4ac9d32431146b378d3 ]
It turned out that on low performance systems the original change can
cause lower tx performance. On a N3450-based mini-PC tx performance
in iperf3 was reduced from 950Mbps to ~900Mbps. Therefore effectively
revert the original change, just use pcie_set_readrq() now instead of
changing the PCIe capability register directly.
Fixes: 2df49d365498 ("r8169: remove fiddling with the PCIe max read request
size")
Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/realtek/r8169_main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index 5ca28985c86b..19ebde91555d 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4099,15 +4099,18 @@ static void rtl_hw_jumbo_enable(struct rtl8169_private
*tp)
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
+ pcie_set_readrq(tp->pci_dev, 512);
r8168b_1_hw_jumbo_enable(tp);
break;
case RTL_GIGA_MAC_VER_18 ... RTL_GIGA_MAC_VER_26:
+ pcie_set_readrq(tp->pci_dev, 512);
r8168c_hw_jumbo_enable(tp);
break;
case RTL_GIGA_MAC_VER_27 ... RTL_GIGA_MAC_VER_28:
r8168dp_hw_jumbo_enable(tp);
break;
case RTL_GIGA_MAC_VER_31 ... RTL_GIGA_MAC_VER_33:
+ pcie_set_readrq(tp->pci_dev, 512);
r8168e_hw_jumbo_enable(tp);
break;
default:
@@ -4137,6 +4140,9 @@ static void rtl_hw_jumbo_disable(struct rtl8169_private
*tp)
break;
}
rtl_lock_config_regs(tp);
+
+ if (pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
+ pcie_set_readrq(tp->pci_dev, 4096);
}
static void rtl_jumbo_config(struct rtl8169_private *tp, int mtu)
--
2.30.2
[PATCH 5.4 67/73] r8169: simplify setting PCI_EXP_DEVCTL_NOSNOOP_EN
From: Heiner Kallweit
[ Upstream commit e0bbe7cbb3c5ff72d680993edf89db2391e80d5d ]
r8168b_0_hw_jumbo_enable() and r8168b_0_hw_jumbo_disable() both do the
same and just set PCI_EXP_DEVCTL_NOSNOOP_EN. We can simplify the code
by moving this setting for RTL8168B to rtl_hw_start_8168().
Signed-off-by: Heiner Kallweit
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/realtek/r8169_main.c | 34 +++
1 file changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index fb11561a4f17..5ca28985c86b 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4083,29 +4083,13 @@ static void r8168e_hw_jumbo_disable(struct
rtl8169_private *tp)
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~0x01);
}
-static void r8168b_0_hw_jumbo_enable(struct rtl8169_private *tp)
-{
- pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
-PCI_EXP_DEVCTL_NOSNOOP_EN);
-}
-
-static void r8168b_0_hw_jumbo_disable(struct rtl8169_private *tp)
-{
- pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
-PCI_EXP_DEVCTL_NOSNOOP_EN);
-}
-
static void r8168b_1_hw_jumbo_enable(struct rtl8169_private *tp)
{
- r8168b_0_hw_jumbo_enable(tp);
-
RTL_W8(tp, Config4, RTL_R8(tp, Config4) | (1 << 0));
}
static void r8168b_1_hw_jumbo_disable(struct rtl8169_private *tp)
{
- r8168b_0_hw_jumbo_disable(tp);
-
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~(1 << 0));
}
@@ -4113,9 +4097,6 @@ static void rtl_hw_jumbo_enable(struct rtl8169_private
*tp)
{
rtl_unlock_config_regs(tp);
switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_11:
- r8168b_0_hw_jumbo_enable(tp);
- break;
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
r8168b_1_hw_jumbo_enable(tp);
@@ -4139,9 +4120,6 @@ static void rtl_hw_jumbo_disable(struct rtl8169_private
*tp)
{
rtl_unlock_config_regs(tp);
switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_11:
- r8168b_0_hw_jumbo_disable(tp);
- break;
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
r8168b_1_hw_jumbo_disable(tp);
@@ -5406,10 +5384,18 @@ static void rtl_hw_start_8125(struct rtl8169_private
*tp)
static void rtl_hw_start_8168(struct rtl8169_private *tp)
{
- if (tp->mac_version == RTL_GIGA_MAC_VER_13 ||
- tp->mac_version == RTL_GIGA_MAC_VER_16)
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_11:
+ case RTL_GIGA_MAC_VER_12:
+ case RTL_GIGA_MAC_VER_13:
+ case RTL_GIGA_MAC_VER_16:
+ case RTL_GIGA_MAC_VER_17:
pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
PCI_EXP_DEVCTL_NOSNOOP_EN);
+ break;
+ default:
+ break;
+ }
if (rtl_is_8168evl_up(tp))
RTL_W8(tp, MaxTxPacketSize, EarlySize);
--
2.30.2
[PATCH 5.4 69/73] r8169: improve rtl_jumbo_config
From: Heiner Kallweit
[ Upstream commit 9db0ac57bd3286fedcf43a86b29b847cea281cc7 ]
Merge enabling and disabling jumbo packets to one function to make
the code a little simpler.
Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/realtek/r8169_main.c | 69 +--
1 file changed, 27 insertions(+), 42 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index 19ebde91555d..1352dd0b69e9 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4093,66 +4093,52 @@ static void r8168b_1_hw_jumbo_disable(struct
rtl8169_private *tp)
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~(1 << 0));
}
-static void rtl_hw_jumbo_enable(struct rtl8169_private *tp)
+static void rtl_jumbo_config(struct rtl8169_private *tp)
{
- rtl_unlock_config_regs(tp);
- switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_12:
- case RTL_GIGA_MAC_VER_17:
- pcie_set_readrq(tp->pci_dev, 512);
- r8168b_1_hw_jumbo_enable(tp);
- break;
- case RTL_GIGA_MAC_VER_18 ... RTL_GIGA_MAC_VER_26:
- pcie_set_readrq(tp->pci_dev, 512);
- r8168c_hw_jumbo_enable(tp);
- break;
- case RTL_GIGA_MAC_VER_27 ... RTL_GIGA_MAC_VER_28:
- r8168dp_hw_jumbo_enable(tp);
- break;
- case RTL_GIGA_MAC_VER_31 ... RTL_GIGA_MAC_VER_33:
- pcie_set_readrq(tp->pci_dev, 512);
- r8168e_hw_jumbo_enable(tp);
- break;
- default:
- break;
- }
- rtl_lock_config_regs(tp);
-}
+ bool jumbo = tp->dev->mtu > ETH_DATA_LEN;
-static void rtl_hw_jumbo_disable(struct rtl8169_private *tp)
-{
rtl_unlock_config_regs(tp);
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
- r8168b_1_hw_jumbo_disable(tp);
+ if (jumbo) {
+ pcie_set_readrq(tp->pci_dev, 512);
+ r8168b_1_hw_jumbo_enable(tp);
+ } else {
+ r8168b_1_hw_jumbo_disable(tp);
+ }
break;
case RTL_GIGA_MAC_VER_18 ... RTL_GIGA_MAC_VER_26:
- r8168c_hw_jumbo_disable(tp);
+ if (jumbo) {
+ pcie_set_readrq(tp->pci_dev, 512);
+ r8168c_hw_jumbo_enable(tp);
+ } else {
+ r8168c_hw_jumbo_disable(tp);
+ }
break;
case RTL_GIGA_MAC_VER_27 ... RTL_GIGA_MAC_VER_28:
- r8168dp_hw_jumbo_disable(tp);
+ if (jumbo)
+ r8168dp_hw_jumbo_enable(tp);
+ else
+ r8168dp_hw_jumbo_disable(tp);
break;
case RTL_GIGA_MAC_VER_31 ... RTL_GIGA_MAC_VER_33:
- r8168e_hw_jumbo_disable(tp);
+ if (jumbo) {
+ pcie_set_readrq(tp->pci_dev, 512);
+ r8168e_hw_jumbo_enable(tp);
+ } else {
+ r8168e_hw_jumbo_disable(tp);
+ }
break;
default:
break;
}
rtl_lock_config_regs(tp);
- if (pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
+ if (!jumbo && pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
pcie_set_readrq(tp->pci_dev, 4096);
}
-static void rtl_jumbo_config(struct rtl8169_private *tp, int mtu)
-{
- if (mtu > ETH_DATA_LEN)
- rtl_hw_jumbo_enable(tp);
- else
- rtl_hw_jumbo_disable(tp);
-}
-
DECLARE_RTL_COND(rtl_chipcmd_cond)
{
return RTL_R8(tp, ChipCmd) & CmdReset;
@@ -5458,7 +5444,7 @@ static void rtl_hw_start(struct rtl8169_private *tp)
rtl_set_rx_tx_desc_registers(tp);
rtl_lock_config_regs(tp);
- rtl_jumbo_config(tp, tp->dev->mtu);
+ rtl_jumbo_config(tp);
/* Initially a 10 us delay. Turned it into a PCI commit. - FR */
RTL_R16(tp, CPlusCmd);
@@ -5473,10 +5459,9 @@ static int rtl8169_change_mtu(struct net_device *dev,
int new_mtu)
{
struct rtl8169_private *tp = netdev_priv(dev);
- rtl_jumbo_config(tp, new_mtu);
-
dev->mtu = new_mtu;
netdev_update_features(dev);
+ rtl_jumbo_config(tp);
/* Reportedly at least Asus X453MA truncates packets otherwise */
if (tp->mac_version == RTL_GIGA_MAC_VER_37)
--
2.30.2
[PATCH 5.4 43/73] dm verity fec: fix misaligned RS roots IO
From: Jaegeuk Kim
commit 8ca7cab82bda4eb0b8064befeeeaa38106cac637 upstream.
commit df7b59ba9245 ("dm verity: fix FEC for RS roots unaligned to
block size") introduced the possibility for misaligned roots IO
relative to the underlying device's logical block size. E.g. Android's
default RS roots=2 results in dm_bufio->block_size=1024, which causes
the following EIO if the logical block size of the device is 4096,
given v->data_dev_block_bits=12:
E sd 0: 0:0:0: [sda] tag#30 request not aligned to the logical block size
E blk_update_request: I/O error, dev sda, sector 10368424 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
E device-mapper: verity-fec: 254:8: FEC 9244672: parity read failed (block
18056): -5
Fix this by onlu using f->roots for dm_bufio blocksize IFF it is
aligned to v->data_dev_block_bits.
Fixes: df7b59ba9245 ("dm verity: fix FEC for RS roots unaligned to block size")
Cc: sta...@vger.kernel.org
Signed-off-by: Jaegeuk Kim
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-verity-fec.c | 11 ---
drivers/md/dm-verity-fec.h |1 +
2 files changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -65,7 +65,7 @@ static u8 *fec_read_parity(struct dm_ver
u8 *res;
position = (index + rsb) * v->fec->roots;
- block = div64_u64_rem(position, v->fec->roots << SECTOR_SHIFT, &rem);
+ block = div64_u64_rem(position, v->fec->io_size, &rem);
*offset = (unsigned)rem;
res = dm_bufio_read(v->fec->bufio, block, buf);
@@ -154,7 +154,7 @@ static int fec_decode_bufs(struct dm_ver
/* read the next block when we run out of parity bytes */
offset += v->fec->roots;
- if (offset >= v->fec->roots << SECTOR_SHIFT) {
+ if (offset >= v->fec->io_size) {
dm_bufio_release(buf);
par = fec_read_parity(v, rsb, block_offset, &offset,
&buf);
@@ -742,8 +742,13 @@ int verity_fec_ctr(struct dm_verity *v)
return -E2BIG;
}
+ if ((f->roots << SECTOR_SHIFT) & ((1 << v->data_dev_block_bits) - 1))
+ f->io_size = 1 << v->data_dev_block_bits;
+ else
+ f->io_size = v->fec->roots << SECTOR_SHIFT;
+
f->bufio = dm_bufio_client_create(f->dev->bdev,
- f->roots << SECTOR_SHIFT,
+ f->io_size,
1, 0, NULL, NULL);
if (IS_ERR(f->bufio)) {
ti->error = "Cannot initialize FEC bufio client";
--- a/drivers/md/dm-verity-fec.h
+++ b/drivers/md/dm-verity-fec.h
@@ -36,6 +36,7 @@ struct dm_verity_fec {
struct dm_dev *dev; /* parity data device */
struct dm_bufio_client *data_bufio; /* for data dev access */
struct dm_bufio_client *bufio; /* for parity data access */
+ size_t io_size; /* IO size for roots */
sector_t start; /* parity data start in blocks */
sector_t blocks;/* number of blocks covered */
sector_t rounds;/* number of interleaving rounds */
[PATCH 5.4 65/73] arm64: dts: allwinner: Fix SD card CD GPIO for SOPine systems
From: Andre Przywara
[ Upstream commit 3dd4ce4185df6798dcdcc3669bddb35899d7d5e1 ]
Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from
SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
along the way with the Pine64-LTS, which share the same base .dtsi.
However while both boards indeed have a working CD GPIO on PF6, the
polarity is different: the SOPine modules uses a "push-pull" socket,
which has an active-high switch, while the Pine64-LTS use the more
traditional push-push socket and the common active-low switch.
Fix the polarity in the sopine.dtsi, and overwrite it in the LTS
board .dts, to make the SD card work again on systems using SOPine
modules.
Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS
SD card")
Reported-by: Ashley
Signed-off-by: Andre Przywara
Signed-off-by: Maxime Ripard
Link: https://lore.kernel.org/r/20210316144219.5973-1-andre.przyw...@arm.com
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 4
arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi| 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
index 72d6961dc312..8d15164f2a3c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
@@ -11,3 +11,7 @@
compatible = "pine64,pine64-lts", "allwinner,sun50i-r18",
"allwinner,sun50i-a64";
};
+
+&mmc0 {
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
index d935e3028fcb..19e5b7e298fd 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
@@ -57,7 +57,7 @@
vmmc-supply = <®_dcdc1>;
disable-wp;
bus-width = <4>;
- cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 push-pull switch */
status = "okay";
};
--
2.30.2
[PATCH 5.4 66/73] r8169: remove fiddling with the PCIe max read request size
From: Heiner Kallweit
[ Upstream commit 2df49d36549808a7357ad9f78b7a8e39516e7809 ]
The attempt to improve performance by changing the PCIe max read request
size was added in the vendor driver more than 10 years back and copied
to r8169 driver. In the vendor driver this has been removed long ago.
Obviously it had no effect, also in my tests I didn't see any
difference. Typically the max payload size is less than 512 bytes
anyway, and the PCI core takes care that the maximum supported value
is set. So let's remove fiddling with PCIe max read request size from
r8169 too.
Signed-off-by: Heiner Kallweit
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/realtek/r8169_main.c | 40 +++
1 file changed, 4 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index bd8decc54b87..fb11561a4f17 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -742,12 +742,6 @@ static void rtl_unlock_config_regs(struct rtl8169_private
*tp)
RTL_W8(tp, Cfg9346, Cfg9346_Unlock);
}
-static void rtl_tx_performance_tweak(struct rtl8169_private *tp, u16 force)
-{
- pcie_capability_clear_and_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
- PCI_EXP_DEVCTL_READRQ, force);
-}
-
static bool rtl_is_8125(struct rtl8169_private *tp)
{
return tp->mac_version >= RTL_GIGA_MAC_VER_60;
@@ -4057,14 +4051,12 @@ static void r8168c_hw_jumbo_enable(struct
rtl8169_private *tp)
{
RTL_W8(tp, Config3, RTL_R8(tp, Config3) | Jumbo_En0);
RTL_W8(tp, Config4, RTL_R8(tp, Config4) | Jumbo_En1);
- rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_512B);
}
static void r8168c_hw_jumbo_disable(struct rtl8169_private *tp)
{
RTL_W8(tp, Config3, RTL_R8(tp, Config3) & ~Jumbo_En0);
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~Jumbo_En1);
- rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
}
static void r8168dp_hw_jumbo_enable(struct rtl8169_private *tp)
@@ -4082,7 +4074,6 @@ static void r8168e_hw_jumbo_enable(struct rtl8169_private
*tp)
RTL_W8(tp, MaxTxPacketSize, 0x24);
RTL_W8(tp, Config3, RTL_R8(tp, Config3) | Jumbo_En0);
RTL_W8(tp, Config4, RTL_R8(tp, Config4) | 0x01);
- rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_512B);
}
static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
@@ -4090,19 +4081,18 @@ static void r8168e_hw_jumbo_disable(struct
rtl8169_private *tp)
RTL_W8(tp, MaxTxPacketSize, 0x3f);
RTL_W8(tp, Config3, RTL_R8(tp, Config3) & ~Jumbo_En0);
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~0x01);
- rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
}
static void r8168b_0_hw_jumbo_enable(struct rtl8169_private *tp)
{
- rtl_tx_performance_tweak(tp,
- PCI_EXP_DEVCTL_READRQ_512B | PCI_EXP_DEVCTL_NOSNOOP_EN);
+ pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
+PCI_EXP_DEVCTL_NOSNOOP_EN);
}
static void r8168b_0_hw_jumbo_disable(struct rtl8169_private *tp)
{
- rtl_tx_performance_tweak(tp,
- PCI_EXP_DEVCTL_READRQ_4096B | PCI_EXP_DEVCTL_NOSNOOP_EN);
+ pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
+PCI_EXP_DEVCTL_NOSNOOP_EN);
}
static void r8168b_1_hw_jumbo_enable(struct rtl8169_private *tp)
@@ -4575,18 +4565,12 @@ static void rtl_hw_start_8168d(struct rtl8169_private
*tp)
rtl_set_def_aspm_entry_latency(tp);
rtl_disable_clock_request(tp);
-
- if (tp->dev->mtu <= ETH_DATA_LEN)
- rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
}
static void rtl_hw_start_8168dp(struct rtl8169_private *tp)
{
rtl_set_def_aspm_entry_latency(tp);
- if (tp->dev->mtu <= ETH_DATA_LEN)
- rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
-
rtl_disable_clock_request(tp);
}
@@ -4601,8 +4585,6 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private
*tp)
rtl_set_def_aspm_entry_latency(tp);
- rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
-
rtl_ephy_init(tp, e_info_8168d_4);
rtl_enable_clock_request(tp);
@@ -4677,8 +4659,6 @@ static void rtl_hw_start_8168f(struct rtl8169_private *tp)
{
rtl_set_def_aspm_entry_latency(tp);
- rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
-
rtl_eri_write(tp, 0xc0, ERIAR_MASK_0011, 0x);
rtl_eri_write(tp, 0xb8, ERIAR_MASK_0011, 0x);
rtl_set_fifo_size(tp, 0x10, 0x10, 0x02, 0x06);
@@ -4741,8 +4721,6 @@ static void rtl_hw_start_8168g(struct rtl8169_private *tp)
rtl_set_def_aspm_entry_latency(tp);
- rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
-
rtl_reset_packet_filter(tp);
rtl_eri_write(tp,
[PATCH 5.4 64/73] ARM: footbridge: fix PCI interrupt mapping
From: Russell King
[ Upstream commit 30e3b4f256b4e366a61658c294f6a21b8626dda7 ]
Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
pci_device_probe()"), the PCI code will call the IRQ mapping function
whenever a PCI driver is probed. If these are marked as __init, this
causes an oops if a PCI driver is loaded or bound after the kernel has
initialised.
Fixes: 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
pci_device_probe()")
Signed-off-by: Russell King
Signed-off-by: Sasha Levin
---
arch/arm/mach-footbridge/cats-pci.c | 4 ++--
arch/arm/mach-footbridge/ebsa285-pci.c | 4 ++--
arch/arm/mach-footbridge/netwinder-pci.c | 2 +-
arch/arm/mach-footbridge/personal-pci.c | 5 ++---
4 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-footbridge/cats-pci.c
b/arch/arm/mach-footbridge/cats-pci.c
index 0b2fd7e2e9b4..90b1e9be430e 100644
--- a/arch/arm/mach-footbridge/cats-pci.c
+++ b/arch/arm/mach-footbridge/cats-pci.c
@@ -15,14 +15,14 @@
#include
/* cats host-specific stuff */
-static int irqmap_cats[] __initdata = { IRQ_PCI, IRQ_IN0, IRQ_IN1, IRQ_IN3 };
+static int irqmap_cats[] = { IRQ_PCI, IRQ_IN0, IRQ_IN1, IRQ_IN3 };
static u8 cats_no_swizzle(struct pci_dev *dev, u8 *pin)
{
return 0;
}
-static int __init cats_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int cats_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
if (dev->irq >= 255)
return -1; /* not a valid interrupt. */
diff --git a/arch/arm/mach-footbridge/ebsa285-pci.c
b/arch/arm/mach-footbridge/ebsa285-pci.c
index 6f28aaa9ca79..c3f280d08fa7 100644
--- a/arch/arm/mach-footbridge/ebsa285-pci.c
+++ b/arch/arm/mach-footbridge/ebsa285-pci.c
@@ -14,9 +14,9 @@
#include
#include
-static int irqmap_ebsa285[] __initdata = { IRQ_IN3, IRQ_IN1, IRQ_IN0, IRQ_PCI
};
+static int irqmap_ebsa285[] = { IRQ_IN3, IRQ_IN1, IRQ_IN0, IRQ_PCI };
-static int __init ebsa285_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int ebsa285_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
if (dev->vendor == PCI_VENDOR_ID_CONTAQ &&
dev->device == PCI_DEVICE_ID_CONTAQ_82C693)
diff --git a/arch/arm/mach-footbridge/netwinder-pci.c
b/arch/arm/mach-footbridge/netwinder-pci.c
index 9473aa0305e5..e8304392074b 100644
--- a/arch/arm/mach-footbridge/netwinder-pci.c
+++ b/arch/arm/mach-footbridge/netwinder-pci.c
@@ -18,7 +18,7 @@
* We now use the slot ID instead of the device identifiers to select
* which interrupt is routed where.
*/
-static int __init netwinder_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int netwinder_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
switch (slot) {
case 0: /* host bridge */
diff --git a/arch/arm/mach-footbridge/personal-pci.c
b/arch/arm/mach-footbridge/personal-pci.c
index 4391e433a4b2..9d19aa98a663 100644
--- a/arch/arm/mach-footbridge/personal-pci.c
+++ b/arch/arm/mach-footbridge/personal-pci.c
@@ -14,13 +14,12 @@
#include
#include
-static int irqmap_personal_server[] __initdata = {
+static int irqmap_personal_server[] = {
IRQ_IN0, IRQ_IN1, IRQ_IN2, IRQ_IN3, 0, 0, 0,
IRQ_DOORBELLHOST, IRQ_DMA1, IRQ_DMA2, IRQ_PCI
};
-static int __init personal_server_map_irq(const struct pci_dev *dev, u8 slot,
- u8 pin)
+static int personal_server_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
unsigned char line;
--
2.30.2
[PATCH 5.4 63/73] gro: ensure frag0 meets IP header alignment
From: Eric Dumazet
commit 38ec4944b593fd90c5ef4253e66ae5769d04 upstream.
After commit 0f6925b3e8da ("virtio_net: Do not pull payload in skb->head")
Guenter Roeck reported one failure in his tests using sh architecture.
After much debugging, we have been able to spot silent unaligned accesses
in inet_gro_receive()
The issue at hand is that upper networking stacks assume their header
is word-aligned. Low level drivers are supposed to reserve NET_IP_ALIGN
bytes before the Ethernet header to make that happen.
This patch hardens skb_gro_reset_offset() to not allow frag0 fast-path
if the fragment is not properly aligned.
Some arches like x86, arm64 and powerpc do not care and define NET_IP_ALIGN
as 0, this extra check will be a NOP for them.
Note that if frag0 is not used, GRO will call pskb_may_pull()
as many times as needed to pull network and transport headers.
Fixes: 0f6925b3e8da ("virtio_net: Do not pull payload in skb->head")
Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual
address")
Signed-off-by: Eric Dumazet
Reported-by: Guenter Roeck
Cc: Xuan Zhuo
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Acked-by: Michael S. Tsirkin
Tested-by: Guenter Roeck
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/core/dev.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5406,7 +5406,8 @@ static void skb_gro_reset_offset(struct
if (skb_mac_header(skb) == skb_tail_pointer(skb) &&
pinfo->nr_frags &&
- !PageHighMem(skb_frag_page(frag0))) {
+ !PageHighMem(skb_frag_page(frag0)) &&
+ (!NET_IP_ALIGN || !(skb_frag_off(frag0) & 3))) {
NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
NAPI_GRO_CB(skb)->frag0_len = min_t(unsigned int,
skb_frag_size(frag0),
[PATCH 5.4 62/73] ibmvnic: remove duplicate napi_schedule call in open function
From: Lijun Pan
commit 7c451f3ef676c805a4b77a743a01a5c21a250a73 upstream.
Remove the unnecessary napi_schedule() call in __ibmvnic_open() since
interrupt_rx() calls napi_schedule_prep/__napi_schedule during every
receive interrupt.
Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/ibm/ibmvnic.c |5 -
1 file changed, 5 deletions(-)
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1088,11 +1088,6 @@ static int __ibmvnic_open(struct net_dev
netif_tx_start_all_queues(netdev);
- if (prev_state == VNIC_CLOSED) {
- for (i = 0; i < adapter->req_rx_queues; i++)
- napi_schedule(&adapter->napi[i]);
- }
-
adapter->state = VNIC_OPEN;
return rc;
}
[PATCH 5.4 73/73] net: phy: marvell: fix detection of PHY on Topaz switches
From: Pali Rohár
commit 1fe976d308acb6374c899a4ee8025a0a016e453e upstream.
Since commit fee2d546414d ("net: phy: marvell: mv88e6390 temperature
sensor reading"), Linux reports the temperature of Topaz hwmon as
constant -75°C.
This is because switches from the Topaz family (88E6141 / 88E6341) have
the address of the temperature sensor register different from Peridot.
This address is instead compatible with 88E1510 PHYs, as was used for
Topaz before the above mentioned commit.
Create a new mapping table between switch family and PHY ID for families
which don't have a model number. And define PHY IDs for Topaz and Peridot
families.
Create a new PHY ID and a new PHY driver for Topaz's internal PHY.
The only difference from Peridot's PHY driver is the HWMON probing
method.
Prior this change Topaz's internal PHY is detected by kernel as:
PHY [...] driver [Marvell 88E6390] (irq=63)
And afterwards as:
PHY [...] driver [Marvell 88E6341 Family] (irq=63)
Signed-off-by: Pali Rohár
BugLink: https://github.com/globalscaletechnologies/linux/issues/1
Fixes: fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor reading")
Reviewed-by: Marek Behún
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/dsa/mv88e6xxx/chip.c | 30 +-
drivers/net/phy/marvell.c| 29 ++---
include/linux/marvell_phy.h |5 +++--
3 files changed, 42 insertions(+), 22 deletions(-)
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2766,10 +2766,17 @@ unlock:
return err;
}
+/* prod_id for switch families which do not have a PHY model number */
+static const u16 family_prod_id_table[] = {
+ [MV88E6XXX_FAMILY_6341] = MV88E6XXX_PORT_SWITCH_ID_PROD_6341,
+ [MV88E6XXX_FAMILY_6390] = MV88E6XXX_PORT_SWITCH_ID_PROD_6390,
+};
+
static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
{
struct mv88e6xxx_mdio_bus *mdio_bus = bus->priv;
struct mv88e6xxx_chip *chip = mdio_bus->chip;
+ u16 prod_id;
u16 val;
int err;
@@ -2780,23 +2787,12 @@ static int mv88e6xxx_mdio_read(struct mi
err = chip->info->ops->phy_read(chip, bus, phy, reg, &val);
mv88e6xxx_reg_unlock(chip);
- if (reg == MII_PHYSID2) {
- /* Some internal PHYs don't have a model number. */
- if (chip->info->family != MV88E6XXX_FAMILY_6165)
- /* Then there is the 6165 family. It gets is
-* PHYs correct. But it can also have two
-* SERDES interfaces in the PHY address
-* space. And these don't have a model
-* number. But they are not PHYs, so we don't
-* want to give them something a PHY driver
-* will recognise.
-*
-* Use the mv88e6390 family model number
-* instead, for anything which really could be
-* a PHY,
-*/
- if (!(val & 0x3f0))
- val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
+ /* Some internal PHYs don't have a model number. */
+ if (reg == MII_PHYSID2 && !(val & 0x3f0) &&
+ chip->info->family < ARRAY_SIZE(family_prod_id_table)) {
+ prod_id = family_prod_id_table[chip->info->family];
+ if (prod_id)
+ val |= prod_id >> 4;
}
return err ? err : val;
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2401,9 +2401,31 @@ static struct phy_driver marvell_drivers
.get_stats = marvell_get_stats,
},
{
- .phy_id = MARVELL_PHY_ID_88E6390,
+ .phy_id = MARVELL_PHY_ID_88E6341_FAMILY,
.phy_id_mask = MARVELL_PHY_ID_MASK,
- .name = "Marvell 88E6390",
+ .name = "Marvell 88E6341 Family",
+ /* PHY_GBIT_FEATURES */
+ .probe = m88e1510_probe,
+ .config_init = &marvell_config_init,
+ .config_aneg = &m88e6390_config_aneg,
+ .read_status = &marvell_read_status,
+ .ack_interrupt = &marvell_ack_interrupt,
+ .config_intr = &marvell_config_intr,
+ .did_interrupt = &m88e1121_did_interrupt,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
+ .read_page = marvell_read_page,
+ .write_page = marvell_write_page,
+ .get_sset_count = marvell_get_sset_count,
+
[PATCH 5.4 61/73] ibmvnic: remove duplicate napi_schedule call in do_reset function
From: Lijun Pan
commit d3a6abccbd272aea7dc2c6f984bb5a2c11278e44 upstream.
During adapter reset, do_reset/do_hard_reset calls ibmvnic_open(),
which will calls napi_schedule if previous state is VNIC_CLOSED
(i.e, the reset case, and "ifconfig down" case). So there is no need
for do_reset to call napi_schedule again at the end of the function
though napi_schedule will neglect the request if napi is already
scheduled.
Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/ibm/ibmvnic.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1849,7 +1849,7 @@ static int do_reset(struct ibmvnic_adapt
u64 old_num_rx_queues, old_num_tx_queues;
u64 old_num_rx_slots, old_num_tx_slots;
struct net_device *netdev = adapter->netdev;
- int i, rc;
+ int rc;
netdev_dbg(adapter->netdev, "Re-setting driver (%d)\n",
rwi->reset_reason);
@@ -1994,10 +1994,6 @@ static int do_reset(struct ibmvnic_adapt
/* refresh device's multicast list */
ibmvnic_set_multi(netdev);
- /* kick napi */
- for (i = 0; i < adapter->req_rx_queues; i++)
- napi_schedule(&adapter->napi[i]);
-
if (adapter->reset_reason == VNIC_RESET_FAILOVER ||
adapter->reset_reason == VNIC_RESET_MOBILITY) {
call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, netdev);
[PATCH 5.4 72/73] ARM: 9071/1: uprobes: Dont hook on thumb instructions
From: Fredrik Strupe
commit d2f7eca60b29006285d57c7035539e33300e89e5 upstream.
Since uprobes is not supported for thumb, check that the thumb bit is
not set when matching the uprobes instruction hooks.
The Arm UDF instructions used for uprobes triggering
(UPROBE_SWBP_ARM_INSN and UPROBE_SS_ARM_INSN) coincidentally share the
same encoding as a pair of unallocated 32-bit thumb instructions (not
UDF) when the condition code is 0b (0xf). This in effect makes it
possible to trigger the uprobes functionality from thumb, and at that
using two unallocated instructions which are not permanently undefined.
Signed-off-by: Fredrik Strupe
Cc: sta...@vger.kernel.org
Fixes: c7edc9e326d5 ("ARM: add uprobes support")
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/probes/uprobes/core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/probes/uprobes/core.c
+++ b/arch/arm/probes/uprobes/core.c
@@ -204,7 +204,7 @@ unsigned long uprobe_get_swbp_addr(struc
static struct undef_hook uprobes_arm_break_hook = {
.instr_mask = 0x0fff,
.instr_val = (UPROBE_SWBP_ARM_INSN & 0x0fff),
- .cpsr_mask = MODE_MASK,
+ .cpsr_mask = (PSR_T_BIT | MODE_MASK),
.cpsr_val = USR_MODE,
.fn = uprobe_trap_handler,
};
@@ -212,7 +212,7 @@ static struct undef_hook uprobes_arm_bre
static struct undef_hook uprobes_arm_ss_hook = {
.instr_mask = 0x0fff,
.instr_val = (UPROBE_SS_ARM_INSN & 0x0fff),
- .cpsr_mask = MODE_MASK,
+ .cpsr_mask = (PSR_T_BIT | MODE_MASK),
.cpsr_val = USR_MODE,
.fn = uprobe_trap_handler,
};
[PATCH 5.4 71/73] r8169: dont advertise pause in jumbo mode
From: Heiner Kallweit
[ Upstream commit 453a77894efa4d9b6ef9644d74b9419c47ac427c ]
It has been reported [0] that using pause frames in jumbo mode impacts
performance. There's no available chip documentation, but vendor
drivers r8168 and r8125 don't advertise pause in jumbo mode. So let's
do the same, according to Roman it fixes the issue.
[0] https://bugzilla.kernel.org/show_bug.cgi?id=212617
Fixes: 9cf9b84cc701 ("r8169: make use of phy_set_asym_pause")
Reported-by: Roman Mamedov
Tested-by: Roman Mamedov
Signed-off-by: Heiner Kallweit
Cc: sta...@vger.kernel.org
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/realtek/r8169_main.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index 4e4953b1433a..8ff178fc2670 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4138,6 +4138,13 @@ static void rtl_jumbo_config(struct rtl8169_private *tp)
if (pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
pcie_set_readrq(tp->pci_dev, readrq);
+
+ /* Chip doesn't support pause in jumbo mode */
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_Pause_BIT,
+tp->phydev->advertising, !jumbo);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
+tp->phydev->advertising, !jumbo);
+ phy_start_aneg(tp->phydev);
}
DECLARE_RTL_COND(rtl_chipcmd_cond)
@@ -6314,8 +6321,6 @@ static int r8169_phy_connect(struct rtl8169_private *tp)
if (!tp->supports_gmii)
phy_set_max_speed(phydev, SPEED_100);
- phy_support_asym_pause(phydev);
-
phy_attached_info(phydev);
return 0;
--
2.30.2
[PATCH 5.4 31/73] net: ieee802154: forbid monitor for add llsec devkey
From: Alexander Aring [ Upstream commit a347b3b394868fef15b16f143719df56184be81d ] This patch forbids to add llsec devkey for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210405003054.256017-11-aahri...@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin --- net/ieee802154/nl802154.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c index 66785e1eb559..65987215dd0c 100644 --- a/net/ieee802154/nl802154.c +++ b/net/ieee802154/nl802154.c @@ -1936,6 +1936,9 @@ static int nl802154_add_llsec_devkey(struct sk_buff *skb, struct genl_info *info struct ieee802154_llsec_device_key key; __le64 extended_addr; + if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) + return -EOPNOTSUPP; + if (!info->attrs[NL802154_ATTR_SEC_DEVKEY] || nla_parse_nested_deprecated(attrs, NL802154_DEVKEY_ATTR_MAX, info->attrs[NL802154_ATTR_SEC_DEVKEY], nl802154_devkey_policy, info->extack) < 0) return -EINVAL; -- 2.30.2
[PATCH 5.4 70/73] r8169: tweak max read request size for newer chips also in jumbo mtu mode
From: Heiner Kallweit
[ Upstream commit 5e00e16cb98935bcf06f51931876d898c226f65c ]
So far we don't increase the max read request size if we switch to
jumbo mode before bringing up the interface for the first time.
Let's change this.
Signed-off-by: Heiner Kallweit
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/realtek/r8169_main.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index 1352dd0b69e9..4e4953b1433a 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4096,13 +4096,14 @@ static void r8168b_1_hw_jumbo_disable(struct
rtl8169_private *tp)
static void rtl_jumbo_config(struct rtl8169_private *tp)
{
bool jumbo = tp->dev->mtu > ETH_DATA_LEN;
+ int readrq = 4096;
rtl_unlock_config_regs(tp);
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
if (jumbo) {
- pcie_set_readrq(tp->pci_dev, 512);
+ readrq = 512;
r8168b_1_hw_jumbo_enable(tp);
} else {
r8168b_1_hw_jumbo_disable(tp);
@@ -4110,7 +4111,7 @@ static void rtl_jumbo_config(struct rtl8169_private *tp)
break;
case RTL_GIGA_MAC_VER_18 ... RTL_GIGA_MAC_VER_26:
if (jumbo) {
- pcie_set_readrq(tp->pci_dev, 512);
+ readrq = 512;
r8168c_hw_jumbo_enable(tp);
} else {
r8168c_hw_jumbo_disable(tp);
@@ -4135,8 +4136,8 @@ static void rtl_jumbo_config(struct rtl8169_private *tp)
}
rtl_lock_config_regs(tp);
- if (!jumbo && pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
- pcie_set_readrq(tp->pci_dev, 4096);
+ if (pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
+ pcie_set_readrq(tp->pci_dev, readrq);
}
DECLARE_RTL_COND(rtl_chipcmd_cond)
--
2.30.2
[PATCH 5.4 44/73] readdir: make sure to verify directory entry for legacy interfaces too
From: Linus Torvalds
commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 upstream.
This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system call
returned just a single entry at a time.
Nobody should use this interface unless you still have binaries from
1991, but let's do it right.
This came up during discussions about unsafe_copy_to_user() and proper
checking of all the inputs to it, as the networking layer is looking to
use it in a few new places. So let's make sure the _old_ users do it
all right and proper, before we add new ones.
See also commit 8a23eb804ca4 ("Make filldir[64]() verify the directory
entry filename is valid") which did the proper modern interfaces that
people actually use. It had a note:
Note that I didn't bother adding the checks to any legacy interfaces
that nobody uses.
which this now corrects. Note that we really don't care about POSIX and
the presense of '/' in a directory entry, but verify_dirent_name() also
ends up doing the proper name length verification which is what the
input checking discussion was about.
[ Another option would be to remove the support for this particular very
old interface: any binaries that use it are likely a.out binaries, and
they will no longer run anyway since we removed a.out binftm support
in commit eac616557050 ("x86: Deprecate a.out support").
But I'm not sure which came first: getdents() or ELF support, so let's
pretend somebody might still have a working binary that uses the
legacy readdir() case.. ]
Link:
https://lore.kernel.org/lkml/CAHk-=wjbvzcahatvg0d81w5o0-kt5ppthhfj5iedfq+bgtg...@mail.gmail.com/
Acked-by: Al Viro
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/readdir.c |6 ++
1 file changed, 6 insertions(+)
--- a/fs/readdir.c
+++ b/fs/readdir.c
@@ -150,6 +150,9 @@ static int fillonedir(struct dir_context
if (buf->result)
return -EINVAL;
+ buf->result = verify_dirent_name(name, namlen);
+ if (buf->result < 0)
+ return buf->result;
d_ino = ino;
if (sizeof(d_ino) < sizeof(ino) && d_ino != ino) {
buf->result = -EOVERFLOW;
@@ -417,6 +420,9 @@ static int compat_fillonedir(struct dir_
if (buf->result)
return -EINVAL;
+ buf->result = verify_dirent_name(name, namlen);
+ if (buf->result < 0)
+ return buf->result;
d_ino = ino;
if (sizeof(d_ino) < sizeof(ino) && d_ino != ino) {
buf->result = -EOVERFLOW;
[PATCH 5.4 42/73] HID: wacom: set EV_KEY and EV_ABS only for non-HID_GENERIC type of devices
From: Ping Cheng
commit 276559d8d02c2709281578976ca2f53bc62063d4 upstream.
Valid HID_GENERIC type of devices set EV_KEY and EV_ABS by wacom_map_usage.
When *_input_capabilities are reached, those devices should already have
their proper EV_* set. EV_KEY and EV_ABS only need to be set for
non-HID_GENERIC type of devices in *_input_capabilities.
Devices that don't support HID descitoprs will pass back to hid-input for
registration without being accidentally rejected by the introduction of
patch: "Input: refuse to register absolute devices without absinfo"
Fixes: 6ecfe51b4082 ("Input: refuse to register absolute devices without
absinfo")
Signed-off-by: Ping Cheng
Reviewed-by: Jason Gerecke
Tested-by: Juan Garrido
CC: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/wacom_wac.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3574,8 +3574,6 @@ int wacom_setup_pen_input_capabilities(s
{
struct wacom_features *features = &wacom_wac->features;
- input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
-
if (!(features->device_type & WACOM_DEVICETYPE_PEN))
return -ENODEV;
@@ -3590,6 +3588,7 @@ int wacom_setup_pen_input_capabilities(s
return 0;
}
+ input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
__set_bit(BTN_TOUCH, input_dev->keybit);
__set_bit(ABS_MISC, input_dev->absbit);
@@ -3742,8 +3741,6 @@ int wacom_setup_touch_input_capabilities
{
struct wacom_features *features = &wacom_wac->features;
- input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
-
if (!(features->device_type & WACOM_DEVICETYPE_TOUCH))
return -ENODEV;
@@ -3756,6 +3753,7 @@ int wacom_setup_touch_input_capabilities
/* setup has already been done */
return 0;
+ input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
__set_bit(BTN_TOUCH, input_dev->keybit);
if (features->touch_max == 1) {
[PATCH 5.4 24/73] net: ieee802154: stop dump llsec keys for monitors
From: Alexander Aring
[ Upstream commit fb3c5cdf88cd504ef11d59e8d656f4bc896c6922 ]
This patch stops dumping llsec keys for monitors which we don't support
yet. Otherwise we will access llsec mib which isn't initialized for
monitors.
Signed-off-by: Alexander Aring
Link: https://lore.kernel.org/r/20210405003054.256017-4-aahri...@redhat.com
Signed-off-by: Stefan Schmidt
Signed-off-by: Sasha Levin
---
net/ieee802154/nl802154.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index f03958fcb5be..27e34aab09a6 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1514,6 +1514,11 @@ nl802154_dump_llsec_key(struct sk_buff *skb, struct
netlink_callback *cb)
if (err)
return err;
+ if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) {
+ err = skb->len;
+ goto out_err;
+ }
+
if (!wpan_dev->netdev) {
err = -EINVAL;
goto out_err;
--
2.30.2
[PATCH 5.4 29/73] net: ieee802154: forbid monitor for del llsec dev
From: Alexander Aring [ Upstream commit ad8f9de1f3566686af35b1c6b43240726541da61 ] This patch forbids to del llsec dev for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210405003054.256017-9-aahri...@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin --- net/ieee802154/nl802154.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c index 797888b4b2ce..4f6777193029 100644 --- a/net/ieee802154/nl802154.c +++ b/net/ieee802154/nl802154.c @@ -1802,6 +1802,9 @@ static int nl802154_del_llsec_dev(struct sk_buff *skb, struct genl_info *info) struct nlattr *attrs[NL802154_DEV_ATTR_MAX + 1]; __le64 extended_addr; + if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) + return -EOPNOTSUPP; + if (!info->attrs[NL802154_ATTR_SEC_DEVICE] || nla_parse_nested_deprecated(attrs, NL802154_DEV_ATTR_MAX, info->attrs[NL802154_ATTR_SEC_DEVICE], nl802154_dev_policy, info->extack)) return -EINVAL; -- 2.30.2
[PATCH 5.4 28/73] net: ieee802154: forbid monitor for add llsec dev
From: Alexander Aring [ Upstream commit 5303f956b05a2886ff42890908156afaec0f95ac ] This patch forbids to add llsec dev for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210405003054.256017-8-aahri...@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin --- net/ieee802154/nl802154.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c index 97074180c2e5..797888b4b2ce 100644 --- a/net/ieee802154/nl802154.c +++ b/net/ieee802154/nl802154.c @@ -1784,6 +1784,9 @@ static int nl802154_add_llsec_dev(struct sk_buff *skb, struct genl_info *info) struct wpan_dev *wpan_dev = dev->ieee802154_ptr; struct ieee802154_llsec_device dev_desc; + if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) + return -EOPNOTSUPP; + if (ieee802154_llsec_parse_device(info->attrs[NL802154_ATTR_SEC_DEVICE], &dev_desc) < 0) return -EINVAL; -- 2.30.2
[PATCH 5.4 27/73] net: ieee802154: stop dump llsec devs for monitors
From: Alexander Aring
[ Upstream commit 5582d641e6740839c9b83efd1fbf9bcd00b6f5fc ]
This patch stops dumping llsec devs for monitors which we don't support
yet. Otherwise we will access llsec mib which isn't initialized for
monitors.
Signed-off-by: Alexander Aring
Link: https://lore.kernel.org/r/20210405003054.256017-7-aahri...@redhat.com
Signed-off-by: Stefan Schmidt
Signed-off-by: Sasha Levin
---
net/ieee802154/nl802154.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 7fdcbaecc4fd..97074180c2e5 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1693,6 +1693,11 @@ nl802154_dump_llsec_dev(struct sk_buff *skb, struct
netlink_callback *cb)
if (err)
return err;
+ if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) {
+ err = skb->len;
+ goto out_err;
+ }
+
if (!wpan_dev->netdev) {
err = -EINVAL;
goto out_err;
--
2.30.2
[PATCH 5.4 26/73] net: ieee802154: forbid monitor for del llsec key
From: Alexander Aring [ Upstream commit b6e2949544a183f590ae6f3ef2d12c44e38a ] This patch forbids to del llsec key for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210405003054.256017-6-aahri...@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin --- net/ieee802154/nl802154.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c index 0920f320b59b..7fdcbaecc4fd 100644 --- a/net/ieee802154/nl802154.c +++ b/net/ieee802154/nl802154.c @@ -1625,6 +1625,9 @@ static int nl802154_del_llsec_key(struct sk_buff *skb, struct genl_info *info) struct nlattr *attrs[NL802154_KEY_ATTR_MAX + 1]; struct ieee802154_llsec_key_id id; + if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) + return -EOPNOTSUPP; + if (!info->attrs[NL802154_ATTR_SEC_KEY] || nla_parse_nested_deprecated(attrs, NL802154_KEY_ATTR_MAX, info->attrs[NL802154_ATTR_SEC_KEY], nl802154_key_policy, info->extack)) return -EINVAL; -- 2.30.2
[PATCH 5.4 59/73] i40e: fix the panic when running bpf in xdpdrv mode
From: Jason Xing
commit 4e39a072a6a0fc422ba7da5e4336bdc295d70211 upstream.
Fix this panic by adding more rules to calculate the value of @rss_size_max
which could be used in allocating the queues when bpf is loaded, which,
however, could cause the failure and then trigger the NULL pointer of
vsi->rx_rings. Prio to this fix, the machine doesn't care about how many
cpus are online and then allocates 256 queues on the machine with 32 cpus
online actually.
Once the load of bpf begins, the log will go like this "failed to get
tracking for 256 queues for VSI 0 err -12" and this "setup of MAIN VSI
failed".
Thus, I attach the key information of the crash-log here.
BUG: unable to handle kernel NULL pointer dereference at
RIP: 0010:i40e_xdp+0xdd/0x1b0 [i40e]
Call Trace:
[2160294.717292] ? i40e_reconfig_rss_queues+0x170/0x170 [i40e]
[2160294.717666] dev_xdp_install+0x4f/0x70
[2160294.718036] dev_change_xdp_fd+0x11f/0x230
[2160294.718380] ? dev_disable_lro+0xe0/0xe0
[2160294.718705] do_setlink+0xac7/0xe70
[2160294.719035] ? __nla_parse+0xed/0x120
[2160294.719365] rtnl_newlink+0x73b/0x860
Fixes: 41c445ff0f48 ("i40e: main driver core")
Co-developed-by: Shujin Li
Signed-off-by: Shujin Li
Signed-off-by: Jason Xing
Reviewed-by: Jesse Brandeburg
Acked-by: Jesper Dangaard Brouer
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/intel/i40e/i40e_main.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11872,6 +11872,7 @@ static int i40e_sw_init(struct i40e_pf *
{
int err = 0;
int size;
+ u16 pow;
/* Set default capability flags */
pf->flags = I40E_FLAG_RX_CSUM_ENABLED |
@@ -11890,6 +11891,11 @@ static int i40e_sw_init(struct i40e_pf *
pf->rss_table_size = pf->hw.func_caps.rss_table_size;
pf->rss_size_max = min_t(int, pf->rss_size_max,
pf->hw.func_caps.num_tx_qp);
+
+ /* find the next higher power-of-2 of num cpus */
+ pow = roundup_pow_of_two(num_online_cpus());
+ pf->rss_size_max = min_t(int, pf->rss_size_max, pow);
+
if (pf->hw.func_caps.rss) {
pf->flags |= I40E_FLAG_RSS_ENABLED;
pf->alloc_rss_size = min_t(int, pf->rss_size_max,
[PATCH 5.4 58/73] net: ip6_tunnel: Unregister catch-all devices
From: Hristo Venev
commit 941ea91e87a6e879ed82dad4949f6234f2702bec upstream.
Similarly to the sit case, we need to remove the tunnels with no
addresses that have been moved to another network namespace.
Fixes: 0bd8762824e73 ("ip6tnl: add x-netns support")
Signed-off-by: Hristo Venev
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv6/ip6_tunnel.c | 10 ++
1 file changed, 10 insertions(+)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -2217,6 +2217,16 @@ static void __net_exit ip6_tnl_destroy_t
t = rtnl_dereference(t->next);
}
}
+
+ t = rtnl_dereference(ip6n->tnls_wc[0]);
+ while (t) {
+ /* If dev is in the same netns, it has already
+* been added to the list by the previous loop.
+*/
+ if (!net_eq(dev_net(t->dev), net))
+ unregister_netdevice_queue(t->dev, list);
+ t = rtnl_dereference(t->next);
+ }
}
static int __net_init ip6_tnl_init_net(struct net *net)
[PATCH 5.4 56/73] net: davicom: Fix regulator not turned off on failed probe
From: Christophe JAILLET
commit 31457db3750c0b0ed229d836f2609fdb8a5b790e upstream.
When the probe fails, we must disable the regulator that was previously
enabled.
This patch is a follow-up to commit ac88c531a5b3
("net: davicom: Fix regulator not turned off on failed probe") which missed
one case.
Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000")
Signed-off-by: Christophe JAILLET
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/davicom/dm9000.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1476,8 +1476,10 @@ dm9000_probe(struct platform_device *pde
/* Init network device */
ndev = alloc_etherdev(sizeof(struct board_info));
- if (!ndev)
- return -ENOMEM;
+ if (!ndev) {
+ ret = -ENOMEM;
+ goto out_regulator_disable;
+ }
SET_NETDEV_DEV(ndev, &pdev->dev);
[PATCH 5.4 57/73] net: sit: Unregister catch-all devices
From: Hristo Venev
commit 610f8c0fc8d46e0933955ce13af3d64484a4630a upstream.
A sit interface created without a local or a remote address is linked
into the `sit_net::tunnels_wc` list of its original namespace. When
deleting a network namespace, delete the devices that have been moved.
The following script triggers a null pointer dereference if devices
linked in a deleted `sit_net` remain:
for i in `seq 1 30`; do
ip netns add ns-test
ip netns exec ns-test ip link add dev veth0 type veth peer veth1
ip netns exec ns-test ip link add dev sit$i type sit dev veth0
ip netns exec ns-test ip link set dev sit$i netns $$
ip netns del ns-test
done
for i in `seq 1 30`; do
ip link del dev sit$i
done
Fixes: 5e6700b3bf98f ("sit: add support of x-netns")
Signed-off-by: Hristo Venev
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv6/sit.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1819,9 +1819,9 @@ static void __net_exit sit_destroy_tunne
if (dev->rtnl_link_ops == &sit_link_ops)
unregister_netdevice_queue(dev, head);
- for (prio = 1; prio < 4; prio++) {
+ for (prio = 0; prio < 4; prio++) {
int h;
- for (h = 0; h < IP6_SIT_HASH_SIZE; h++) {
+ for (h = 0; h < (prio ? IP6_SIT_HASH_SIZE : 1); h++) {
struct ip_tunnel *t;
t = rtnl_dereference(sitn->tunnels[prio][h]);
[PATCH 5.4 54/73] net: macb: fix the restore of cmp registers
From: Claudiu Beznea
commit a714e27ea8bdee2b238748029d31472d0a65b611 upstream.
Commit a14d273ba159 ("net: macb: restore cmp registers on resume path")
introduces the restore of CMP registers on resume path. In case the IP
doesn't support type 2 screeners (zero on DCFG8 register) the
struct macb::rx_fs_list::list is not initialized and thus the
list_for_each_entry(item, &bp->rx_fs_list.list, list) loop introduced in
commit a14d273ba159 ("net: macb: restore cmp registers on resume path")
will access an uninitialized list leading to crash. Thus, initialize
the struct macb::rx_fs_list::list without taking into account if the
IP supports type 2 screeners or not.
Fixes: a14d273ba159 ("net: macb: restore cmp registers on resume path")
Signed-off-by: Claudiu Beznea
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/cadence/macb_main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3590,6 +3590,7 @@ static int macb_init(struct platform_dev
reg = gem_readl(bp, DCFG8);
bp->max_tuples = min((GEM_BFEXT(SCR2CMP, reg) / 3),
GEM_BFEXT(T2SCR, reg));
+ INIT_LIST_HEAD(&bp->rx_fs_list.list);
if (bp->max_tuples > 0) {
/* also needs one ethtype match to check IPv4 */
if (GEM_BFEXT(SCR2ETH, reg) > 0) {
@@ -3600,7 +3601,6 @@ static int macb_init(struct platform_dev
/* Filtering is supported in hw but don't enable it in
kernel now */
dev->hw_features |= NETIF_F_NTUPLE;
/* init Rx flow definitions */
- INIT_LIST_HEAD(&bp->rx_fs_list.list);
bp->rx_fs_list.count = 0;
spin_lock_init(&bp->rx_fs_lock);
} else
[PATCH 5.4 55/73] netfilter: nft_limit: avoid possible divide error in nft_limit_init
From: Eric Dumazet
commit b895bdf5d643b6feb7c60856326dd4feb6981560 upstream.
div_u64() divides u64 by u32.
nft_limit_init() wants to divide u64 by u64, use the appropriate
math function (div64_u64)
divide error: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:div_u64_rem include/linux/math64.h:28 [inline]
RIP: 0010:div_u64 include/linux/math64.h:127 [inline]
RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85
Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00
00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3
9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00
RSP: 0018:c90009447198 EFLAGS: 00010246
RAX: RBX: 2000 RCX:
RDX: RSI: 875152e6 RDI: 0003
RBP: 888020f80908 R08: 2000 R09:
R10: 875152d8 R11: R12: c90009447270
R13: R14: R15:
FS: 0097a300() GS:8880b9d0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 21c4 CR3: 26a52000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline]
nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713
nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160
nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321
nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456
nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline]
nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598
netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixes: c26844eda9d4 ("netfilter: nf_tables: Fix nft limit burst handling")
Fixes: 3e0f64b7dd31 ("netfilter: nft_limit: fix packet ratelimiting")
Signed-off-by: Eric Dumazet
Diagnosed-by: Luigi Rizzo
Reported-by: syzbot
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman
---
net/netfilter/nft_limit.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/netfilter/nft_limit.c
+++ b/net/netfilter/nft_limit.c
@@ -76,13 +76,13 @@ static int nft_limit_init(struct nft_lim
return -EOVERFLOW;
if (pkts) {
- tokens = div_u64(limit->nsecs, limit->rate) * limit->burst;
+ tokens = div64_u64(limit->nsecs, limit->rate) * limit->burst;
} else {
/* The token bucket size limits the number of tokens can be
* accumulated. tokens_max specifies the bucket size.
* tokens_max = unit * (rate + burst) / rate.
*/
- tokens = div_u64(limit->nsecs * (limit->rate + limit->burst),
+ tokens = div64_u64(limit->nsecs * (limit->rate + limit->burst),
limit->rate);
}
[PATCH 5.4 51/73] libnvdimm/region: Fix nvdimm_has_flush() to handle ND_REGION_ASYNC
From: Vaibhav Jain
commit a2948b17f6b936fc52f86c0f92c46d2f91928b79 upstream.
In case a platform doesn't provide explicit flush-hints but provides an
explicit flush callback via ND_REGION_ASYNC region flag, then
nvdimm_has_flush() still returns '0' indicating that writes do not
require flushing. This happens on PPC64 with patch at [1] applied, where
'deep_flush' of a region was denied even though an explicit flush
function was provided.
Fix this by adding a condition to nvdimm_has_flush() to test for the
ND_REGION_ASYNC flag on the region and see if a 'region->flush' callback
is assigned.
Link:
http://lore.kernel.org/r/161703936121.36.7260632399582101498.stgit@e1fbed493c87
[1]
Fixes: c5d4355d10d4 ("libnvdimm: nd_region flush callback support")
Reported-by: Shivaprasad G Bhat
Signed-off-by: Vaibhav Jain
Link: https://lore.kernel.org/r/20210402092555.208590-1-vaib...@linux.ibm.com
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman
---
drivers/nvdimm/region_devs.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -1142,6 +1142,11 @@ int nvdimm_has_flush(struct nd_region *n
|| !IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API))
return -ENXIO;
+ /* Test if an explicit flush function is defined */
+ if (test_bit(ND_REGION_ASYNC, &nd_region->flags) && nd_region->flush)
+ return 1;
+
+ /* Test if any flush hints for the region are available */
for (i = 0; i < nd_region->ndr_mappings; i++) {
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
struct nvdimm *nvdimm = nd_mapping->nvdimm;
@@ -1152,8 +1157,8 @@ int nvdimm_has_flush(struct nd_region *n
}
/*
-* The platform defines dimm devices without hints, assume
-* platform persistence mechanism like ADR
+* The platform defines dimm devices without hints nor explicit flush,
+* assume platform persistence mechanism like ADR
*/
return 0;
}
[PATCH 5.4 50/73] netfilter: conntrack: do not print icmpv6 as unknown via /proc
From: Pablo Neira Ayuso
commit fbea31808ca124dd73ff6bb1e67c9af4607c3e32 upstream.
/proc/net/nf_conntrack shows icmpv6 as unknown.
Fixes: 09ec82f5af99 ("netfilter: conntrack: remove protocol name from l4proto
struct")
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman
---
net/netfilter/nf_conntrack_standalone.c |1 +
1 file changed, 1 insertion(+)
--- a/net/netfilter/nf_conntrack_standalone.c
+++ b/net/netfilter/nf_conntrack_standalone.c
@@ -266,6 +266,7 @@ static const char* l4proto_name(u16 prot
case IPPROTO_GRE: return "gre";
case IPPROTO_SCTP: return "sctp";
case IPPROTO_UDPLITE: return "udplite";
+ case IPPROTO_ICMPV6: return "icmpv6";
}
return "unknown";
[PATCH 5.4 53/73] netfilter: arp_tables: add pre_exit hook for table unregister
From: Florian Westphal
commit d163a925ebbc6eb5b562b0f1d72c7e817aa75c40 upstream.
Same problem that also existed in iptables/ip(6)tables, when
arptable_filter is removed there is no longer a wait period before the
table/ruleset is free'd.
Unregister the hook in pre_exit, then remove the table in the exit
function.
This used to work correctly because the old nf_hook_unregister API
did unconditional synchronize_net.
The per-net hook unregister function uses call_rcu instead.
Fixes: b9e69e127397 ("netfilter: xtables: don't hook tables by default")
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman
---
include/linux/netfilter_arp/arp_tables.h |5 +++--
net/ipv4/netfilter/arp_tables.c |9 +++--
net/ipv4/netfilter/arptable_filter.c | 10 +-
3 files changed, 19 insertions(+), 5 deletions(-)
--- a/include/linux/netfilter_arp/arp_tables.h
+++ b/include/linux/netfilter_arp/arp_tables.h
@@ -52,8 +52,9 @@ extern void *arpt_alloc_initial_table(co
int arpt_register_table(struct net *net, const struct xt_table *table,
const struct arpt_replace *repl,
const struct nf_hook_ops *ops, struct xt_table **res);
-void arpt_unregister_table(struct net *net, struct xt_table *table,
- const struct nf_hook_ops *ops);
+void arpt_unregister_table(struct net *net, struct xt_table *table);
+void arpt_unregister_table_pre_exit(struct net *net, struct xt_table *table,
+ const struct nf_hook_ops *ops);
extern unsigned int arpt_do_table(struct sk_buff *skb,
const struct nf_hook_state *state,
struct xt_table *table);
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -1580,10 +1580,15 @@ out_free:
return ret;
}
-void arpt_unregister_table(struct net *net, struct xt_table *table,
- const struct nf_hook_ops *ops)
+void arpt_unregister_table_pre_exit(struct net *net, struct xt_table *table,
+ const struct nf_hook_ops *ops)
{
nf_unregister_net_hooks(net, ops, hweight32(table->valid_hooks));
+}
+EXPORT_SYMBOL(arpt_unregister_table_pre_exit);
+
+void arpt_unregister_table(struct net *net, struct xt_table *table)
+{
__arpt_unregister_table(net, table);
}
--- a/net/ipv4/netfilter/arptable_filter.c
+++ b/net/ipv4/netfilter/arptable_filter.c
@@ -56,16 +56,24 @@ static int __net_init arptable_filter_ta
return err;
}
+static void __net_exit arptable_filter_net_pre_exit(struct net *net)
+{
+ if (net->ipv4.arptable_filter)
+ arpt_unregister_table_pre_exit(net, net->ipv4.arptable_filter,
+ arpfilter_ops);
+}
+
static void __net_exit arptable_filter_net_exit(struct net *net)
{
if (!net->ipv4.arptable_filter)
return;
- arpt_unregister_table(net, net->ipv4.arptable_filter, arpfilter_ops);
+ arpt_unregister_table(net, net->ipv4.arptable_filter);
net->ipv4.arptable_filter = NULL;
}
static struct pernet_operations arptable_filter_net_ops = {
.exit = arptable_filter_net_exit,
+ .pre_exit = arptable_filter_net_pre_exit,
};
static int __init arptable_filter_init(void)
[PATCH 5.4 49/73] scsi: libsas: Reset num_scatter if libata marks qc as NODATA
From: Jolly Shah
commit 176ddd89171ddcf661862d90c5d257877f7326d6 upstream.
When the cache_type for the SCSI device is changed, the SCSI layer issues a
MODE_SELECT command. The caching mode details are communicated via a
request buffer associated with the SCSI command with data direction set as
DMA_TO_DEVICE (scsi_mode_select()). When this command reaches the libata
layer, as a part of generic initial setup, libata layer sets up the
scatterlist for the command using the SCSI command (ata_scsi_qc_new()).
This command is then translated by the libata layer into
ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat()). The libata layer treats
this as a non-data command (ata_mselect_caching()), since it only needs an
ATA taskfile to pass the caching on/off information to the device. It does
not need the scatterlist that has been setup, so it does not perform
dma_map_sg() on the scatterlist (ata_qc_issue()). Unfortunately, when this
command reaches the libsas layer (sas_ata_qc_issue()), libsas layer sees it
as a non-data command with a scatterlist. It cannot extract the correct DMA
length since the scatterlist has not been mapped with dma_map_sg() for a
DMA operation. When this partially constructed SAS task reaches pm80xx
LLDD, it results in the following warning:
"pm80xx_chip_sata_req 6058: The sg list address
start_addr=0x data_len=0x0end_addr_high=0x
end_addr_low=0x has crossed 4G boundary"
Update libsas to handle ATA non-data commands separately so num_scatter and
total_xfer_len remain 0.
Link: https://lore.kernel.org/r/20210318225632.2481291-1-jol...@google.com
Fixes: 53de092f47ff ("scsi: libsas: Set data_dir as DMA_NONE if libata marks qc
as NODATA")
Tested-by: Luo Jiaxing
Reviewed-by: John Garry
Signed-off-by: Jolly Shah
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/libsas/sas_ata.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -200,18 +200,17 @@ static unsigned int sas_ata_qc_issue(str
memcpy(task->ata_task.atapi_packet, qc->cdb, qc->dev->cdb_len);
task->total_xfer_len = qc->nbytes;
task->num_scatter = qc->n_elem;
+ task->data_dir = qc->dma_dir;
+ } else if (qc->tf.protocol == ATA_PROT_NODATA) {
+ task->data_dir = DMA_NONE;
} else {
for_each_sg(qc->sg, sg, qc->n_elem, si)
xfer += sg_dma_len(sg);
task->total_xfer_len = xfer;
task->num_scatter = si;
- }
-
- if (qc->tf.protocol == ATA_PROT_NODATA)
- task->data_dir = DMA_NONE;
- else
task->data_dir = qc->dma_dir;
+ }
task->scatter = qc->sg;
task->ata_task.retry_count = 1;
task->task_state_flags = SAS_TASK_STATE_PENDING;
[PATCH 5.4 25/73] net: ieee802154: forbid monitor for add llsec key
From: Alexander Aring
[ Upstream commit 08470c5453339369bd3d590c4cbb0b5961cdcbb6 ]
This patch forbids to add llsec key for monitor interfaces which we
don't support yet. Otherwise we will access llsec mib which isn't
initialized for monitors.
Signed-off-by: Alexander Aring
Link: https://lore.kernel.org/r/20210405003054.256017-5-aahri...@redhat.com
Signed-off-by: Stefan Schmidt
Signed-off-by: Sasha Levin
---
net/ieee802154/nl802154.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 27e34aab09a6..0920f320b59b 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1573,6 +1573,9 @@ static int nl802154_add_llsec_key(struct sk_buff *skb,
struct genl_info *info)
struct ieee802154_llsec_key_id id = { };
u32 commands[NL802154_CMD_FRAME_NR_IDS / 32] = { };
+ if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR)
+ return -EOPNOTSUPP;
+
if (!info->attrs[NL802154_ATTR_SEC_KEY] ||
nla_parse_nested_deprecated(attrs, NL802154_KEY_ATTR_MAX,
info->attrs[NL802154_ATTR_SEC_KEY], nl802154_key_policy, info->extack))
return -EINVAL;
--
2.30.2
[PATCH 5.4 52/73] netfilter: bridge: add pre_exit hooks for ebtable unregistration
From: Florian Westphal
commit 7ee3c61dcd28bf6e290e06ad382f13511dc790e9 upstream.
Just like ip/ip6/arptables, the hooks have to be removed, then
synchronize_rcu() has to be called to make sure no more packets are being
processed before the ruleset data is released.
Place the hook unregistration in the pre_exit hook, then call the new
ebtables pre_exit function from there.
Years ago, when first netns support got added for netfilter+ebtables,
this used an older (now removed) netfilter hook unregister API, that did
a unconditional synchronize_rcu().
Now that all is done with call_rcu, ebtable_{filter,nat,broute} pernet exit
handlers may free the ebtable ruleset while packets are still in flight.
This can only happens on module removal, not during netns exit.
The new function expects the table name, not the table struct.
This is because upcoming patch set (targeting -next) will remove all
net->xt.{nat,filter,broute}_table instances, this makes it necessary
to avoid external references to those member variables.
The existing APIs will be converted, so follow the upcoming scheme of
passing name + hook type instead.
Fixes: aee12a0a3727e ("ebtables: remove nf_hook_register usage")
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman
---
include/linux/netfilter_bridge/ebtables.h |5 +++--
net/bridge/netfilter/ebtable_broute.c |8 +++-
net/bridge/netfilter/ebtable_filter.c |8 +++-
net/bridge/netfilter/ebtable_nat.c|8 +++-
net/bridge/netfilter/ebtables.c | 30 +++---
5 files changed, 51 insertions(+), 8 deletions(-)
--- a/include/linux/netfilter_bridge/ebtables.h
+++ b/include/linux/netfilter_bridge/ebtables.h
@@ -110,8 +110,9 @@ extern int ebt_register_table(struct net
const struct ebt_table *table,
const struct nf_hook_ops *ops,
struct ebt_table **res);
-extern void ebt_unregister_table(struct net *net, struct ebt_table *table,
-const struct nf_hook_ops *);
+extern void ebt_unregister_table(struct net *net, struct ebt_table *table);
+void ebt_unregister_table_pre_exit(struct net *net, const char *tablename,
+ const struct nf_hook_ops *ops);
extern unsigned int ebt_do_table(struct sk_buff *skb,
const struct nf_hook_state *state,
struct ebt_table *table);
--- a/net/bridge/netfilter/ebtable_broute.c
+++ b/net/bridge/netfilter/ebtable_broute.c
@@ -105,14 +105,20 @@ static int __net_init broute_net_init(st
&net->xt.broute_table);
}
+static void __net_exit broute_net_pre_exit(struct net *net)
+{
+ ebt_unregister_table_pre_exit(net, "broute", &ebt_ops_broute);
+}
+
static void __net_exit broute_net_exit(struct net *net)
{
- ebt_unregister_table(net, net->xt.broute_table, &ebt_ops_broute);
+ ebt_unregister_table(net, net->xt.broute_table);
}
static struct pernet_operations broute_net_ops = {
.init = broute_net_init,
.exit = broute_net_exit,
+ .pre_exit = broute_net_pre_exit,
};
static int __init ebtable_broute_init(void)
--- a/net/bridge/netfilter/ebtable_filter.c
+++ b/net/bridge/netfilter/ebtable_filter.c
@@ -99,14 +99,20 @@ static int __net_init frame_filter_net_i
&net->xt.frame_filter);
}
+static void __net_exit frame_filter_net_pre_exit(struct net *net)
+{
+ ebt_unregister_table_pre_exit(net, "filter", ebt_ops_filter);
+}
+
static void __net_exit frame_filter_net_exit(struct net *net)
{
- ebt_unregister_table(net, net->xt.frame_filter, ebt_ops_filter);
+ ebt_unregister_table(net, net->xt.frame_filter);
}
static struct pernet_operations frame_filter_net_ops = {
.init = frame_filter_net_init,
.exit = frame_filter_net_exit,
+ .pre_exit = frame_filter_net_pre_exit,
};
static int __init ebtable_filter_init(void)
--- a/net/bridge/netfilter/ebtable_nat.c
+++ b/net/bridge/netfilter/ebtable_nat.c
@@ -99,14 +99,20 @@ static int __net_init frame_nat_net_init
&net->xt.frame_nat);
}
+static void __net_exit frame_nat_net_pre_exit(struct net *net)
+{
+ ebt_unregister_table_pre_exit(net, "nat", ebt_ops_nat);
+}
+
static void __net_exit frame_nat_net_exit(struct net *net)
{
- ebt_unregister_table(net, net->xt.frame_nat, ebt_ops_nat);
+ ebt_unregister_table(net, net->xt.frame_nat);
}
static struct pernet_operations frame_nat_net_ops = {
.init = frame_nat_net_init,
.exit = frame_nat_net_exit,
+ .pre_exit = frame_nat_net_pre_exit,
};
static int __init ebtable_nat_init(void)
--- a/net/bridge/netfilter/ebtables.c
+++ b/n
[PATCH 5.4 48/73] riscv: Fix spelling mistake "SPARSEMEM" to "SPARSMEM"
From: Kefeng Wang
commit 199fc6b8dee7d6d50467a57e0dc7e3e1b7d59966 upstream.
There is a spelling mistake when SPARSEMEM Kconfig copy.
Fixes: a5406a7ff56e ("riscv: Correct SPARSEMEM configuration")
Cc: sta...@vger.kernel.org
Signed-off-by: Kefeng Wang
Signed-off-by: Palmer Dabbelt
Signed-off-by: Greg Kroah-Hartman
---
arch/riscv/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -101,7 +101,7 @@ config ARCH_FLATMEM_ENABLE
config ARCH_SPARSEMEM_ENABLE
def_bool y
depends on MMU
- select SPARSEMEM_STATIC if 32BIT && SPARSMEM
+ select SPARSEMEM_STATIC if 32BIT && SPARSEMEM
select SPARSEMEM_VMEMMAP_ENABLE if 64BIT
config ARCH_SELECT_MEMORY_MODEL
[PATCH 5.4 47/73] vfio/pci: Add missing range check in vfio_pci_mmap
From: Christian A. Ehrhardt
commit 909290786ea335366e21d7f1ed5812b90f2f0a92 upstream.
When mmaping an extra device region verify that the region index
derived from the mmap offset is valid.
Fixes: a15b1883fee1 ("vfio_pci: Allow mapping extra regions")
Cc: sta...@vger.kernel.org
Signed-off-by: Christian A. Ehrhardt
Message-Id: <20210412214124.ga241...@lisa.in-ulm.de>
Reviewed-by: David Gibson
Reviewed-by: Cornelia Huck
Signed-off-by: Alex Williamson
Signed-off-by: Greg Kroah-Hartman
---
drivers/vfio/pci/vfio_pci.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1474,6 +1474,8 @@ static int vfio_pci_mmap(void *device_da
index = vma->vm_pgoff >> (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT);
+ if (index >= VFIO_PCI_NUM_REGIONS + vdev->num_regions)
+ return -EINVAL;
if (vma->vm_end < vma->vm_start)
return -EINVAL;
if ((vma->vm_flags & VM_SHARED) == 0)
@@ -1482,7 +1484,7 @@ static int vfio_pci_mmap(void *device_da
int regnum = index - VFIO_PCI_NUM_REGIONS;
struct vfio_pci_region *region = vdev->region + regnum;
- if (region && region->ops && region->ops->mmap &&
+ if (region->ops && region->ops->mmap &&
(region->flags & VFIO_REGION_INFO_FLAG_MMAP))
return region->ops->mmap(vdev, region, vma);
return -EINVAL;
[PATCH 5.4 46/73] arm64: alternatives: Move length validation in alternative_{insn, endif}
From: Nathan Chancellor
commit 22315a2296f4c251fa92aec45fbbae37e9301b6c upstream.
After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
set atomically"), LLVM's integrated assembler fails to build entry.S:
:5:7: error: expected assembly-time absolute expression
.org . - (664b-663b) + (662b-661b)
^
:6:7: error: expected assembly-time absolute expression
.org . - (662b-661b) + (664b-663b)
^
The root cause is LLVM's assembler has a one-pass design, meaning it
cannot figure out these instruction lengths when the .org directive is
outside of the subsection that they are in, which was changed by the
.arch_extension directive added in the above commit.
Apply the same fix from commit 966a0acce2fc ("arm64/alternatives: move
length validation inside the subsection") to the alternative_endif
macro, shuffling the .org directives so that the length validation
happen will always happen in the same subsections. alternative_insn has
not shown any issue yet but it appears that it could have the same issue
in the future so just preemptively change it.
Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement
sequences")
Cc: # 5.8.x
Link: https://github.com/ClangBuiltLinux/linux/issues/1347
Signed-off-by: Nathan Chancellor
Reviewed-by: Sami Tolvanen
Tested-by: Sami Tolvanen
Reviewed-by: Nick Desaulniers
Tested-by: Nick Desaulniers
Link: https://lore.kernel.org/r/20210414000803.662534-1-nat...@kernel.org
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/include/asm/alternative.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -119,9 +119,9 @@ static inline void apply_alternatives_mo
.popsection
.subsection 1
663: \insn2
-664: .previous
- .org. - (664b-663b) + (662b-661b)
+664: .org. - (664b-663b) + (662b-661b)
.org. - (662b-661b) + (664b-663b)
+ .previous
.endif
.endm
@@ -191,11 +191,11 @@ static inline void apply_alternatives_mo
*/
.macro alternative_endif
664:
+ .org. - (664b-663b) + (662b-661b)
+ .org. - (662b-661b) + (664b-663b)
.if .Lasm_alt_mode==0
.previous
.endif
- .org. - (664b-663b) + (662b-661b)
- .org. - (662b-661b) + (664b-663b)
.endm
/*
[PATCH 5.4 45/73] arm64: fix inline asm in load_unaligned_zeropad()
From: Peter Collingbourne
commit 185f2e5f51c2029efd9dd26cceb968a44fe053c6 upstream.
The inline asm's addr operand is marked as input-only, however in
the case where an exception is taken it may be modified by the BIC
instruction on the exception path. Fix the problem by using a temporary
register as the destination register for the BIC instruction.
Signed-off-by: Peter Collingbourne
Cc: sta...@vger.kernel.org
Link:
https://linux-review.googlesource.com/id/I84538c8a2307d567b4f45bb20b715451005f9617
Link: https://lore.kernel.org/r/20210401165110.3952103-1-...@google.com
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/include/asm/word-at-a-time.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/arm64/include/asm/word-at-a-time.h
+++ b/arch/arm64/include/asm/word-at-a-time.h
@@ -53,7 +53,7 @@ static inline unsigned long find_zero(un
*/
static inline unsigned long load_unaligned_zeropad(const void *addr)
{
- unsigned long ret, offset;
+ unsigned long ret, tmp;
/* Load word from unaligned pointer addr */
asm(
@@ -61,9 +61,9 @@ static inline unsigned long load_unalign
"2:\n"
" .pushsection .fixup,\"ax\"\n"
" .align 2\n"
- "3: and %1, %2, #0x7\n"
- " bic %2, %2, #0x7\n"
- " ldr %0, [%2]\n"
+ "3: bic %1, %2, #0x7\n"
+ " ldr %0, [%1]\n"
+ " and %1, %2, #0x7\n"
" lsl %1, %1, #0x3\n"
#ifndef __AARCH64EB__
" lsr %0, %0, %1\n"
@@ -73,7 +73,7 @@ static inline unsigned long load_unalign
" b 2b\n"
" .popsection\n"
_ASM_EXTABLE(1b, 3b)
- : "=&r" (ret), "=&r" (offset)
+ : "=&r" (ret), "=&r" (tmp)
: "r" (addr), "Q" (*(unsigned long *)addr));
return ret;
[PATCH 5.4 41/73] Input: i8042 - fix Pegatron C15B ID entry
From: Arnd Bergmann
commit daa58c8eec0a65ac8e2e77ff3ea8a233d8eec954 upstream.
The Zenbook Flip entry that was added overwrites a previous one
because of a typo:
In file included from drivers/input/serio/i8042.h:23,
from drivers/input/serio/i8042.c:131:
drivers/input/serio/i8042-x86ia64io.h:591:28: error: initialized field
overwritten [-Werror=override-init]
591 | .matches = {
|^
drivers/input/serio/i8042-x86ia64io.h:591:28: note: (near initialization for
'i8042_dmi_noselftest_table[0].matches')
Add the missing separator between the two.
Fixes: b5d6e7ab7fe7 ("Input: i8042 - add ASUS Zenbook Flip to noselftest list")
Signed-off-by: Arnd Bergmann
Reviewed-by: Hans de Goede
Reviewed-by: Marcos Paulo de Souza
Link: https://lore.kernel.org/r/20210323130623.2302402-1-a...@kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/serio/i8042-x86ia64io.h |1 +
1 file changed, 1 insertion(+)
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -588,6 +588,7 @@ static const struct dmi_system_id i8042_
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
},
+ }, {
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_CHASSIS_TYPE, "31"), /* Convertible
Notebook */
[PATCH 5.4 03/73] scsi: qla2xxx: Dual FCP-NVMe target port support
From: Michael Hernandez
[ Upstream commit 84ed362ac40ca44dbbbebf767301463aa72bc797 ]
Some storage arrays advertise FCP LUNs and NVMe namespaces behind the same
WWN. The driver now offers a user option by way of NVRAM parameter to
allow users to choose, on a per port basis, the kind of FC-4 type they
would like to prioritize for login.
Link: https://lore.kernel.org/r/20190912180918.6436-9-hmadh...@marvell.com
Signed-off-by: Michael Hernandez
Signed-off-by: Himanshu Madhani
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/qla2xxx/qla_def.h| 26 -
drivers/scsi/qla2xxx/qla_fw.h | 2 +
drivers/scsi/qla2xxx/qla_gs.c | 42
drivers/scsi/qla2xxx/qla_init.c | 64 ++-
drivers/scsi/qla2xxx/qla_inline.h | 12 ++
drivers/scsi/qla2xxx/qla_mbx.c| 11 +++---
drivers/scsi/qla2xxx/qla_os.c | 17
7 files changed, 114 insertions(+), 60 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 1eb3fe281cc3..894c2716b7ce 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -2281,7 +2281,7 @@ typedef struct {
uint8_t fabric_port_name[WWN_SIZE];
uint16_t fp_speed;
uint8_t fc4_type;
- uint8_t fc4f_nvme; /* nvme fc4 feature bits */
+ uint8_t fc4_features;
} sw_info_t;
/* FCP-4 types */
@@ -2450,7 +2450,7 @@ typedef struct fc_port {
u32 supported_classes;
uint8_t fc4_type;
- uint8_t fc4f_nvme;
+ uint8_t fc4_features;
uint8_t scan_state;
unsigned long last_queue_full;
@@ -2481,6 +2481,9 @@ typedef struct fc_port {
u16 n2n_chip_reset;
} fc_port_t;
+#define FC4_PRIORITY_NVME 0
+#define FC4_PRIORITY_FCP 1
+
#define QLA_FCPORT_SCAN1
#define QLA_FCPORT_FOUND 2
@@ -4296,6 +4299,8 @@ struct qla_hw_data {
atomic_tnvme_active_aen_cnt;
uint16_tnvme_last_rptd_aen; /* Last recorded aen
count */
+ uint8_t fc4_type_priority;
+
atomic_t zio_threshold;
uint16_t last_zio_threshold;
@@ -4821,6 +4826,23 @@ struct sff_8247_a0 {
ha->current_topology == ISP_CFG_N || \
!ha->current_topology)
+#define NVME_TYPE(fcport) \
+ (fcport->fc4_type & FS_FC4TYPE_NVME) \
+
+#define FCP_TYPE(fcport) \
+ (fcport->fc4_type & FS_FC4TYPE_FCP) \
+
+#define NVME_ONLY_TARGET(fcport) \
+ (NVME_TYPE(fcport) && !FCP_TYPE(fcport)) \
+
+#define NVME_FCP_TARGET(fcport) \
+ (FCP_TYPE(fcport) && NVME_TYPE(fcport)) \
+
+#define NVME_TARGET(ha, fcport) \
+ ((NVME_FCP_TARGET(fcport) && \
+ (ha->fc4_type_priority == FC4_PRIORITY_NVME)) || \
+ NVME_ONLY_TARGET(fcport)) \
+
#include "qla_target.h"
#include "qla_gbl.h"
#include "qla_dbg.h"
diff --git a/drivers/scsi/qla2xxx/qla_fw.h b/drivers/scsi/qla2xxx/qla_fw.h
index dc2366a29665..9dc09c117416 100644
--- a/drivers/scsi/qla2xxx/qla_fw.h
+++ b/drivers/scsi/qla2xxx/qla_fw.h
@@ -2105,4 +2105,6 @@ struct qla_fcp_prio_cfg {
#define FA_FLASH_LAYOUT_ADDR_83(0x3F1000/4)
#define FA_FLASH_LAYOUT_ADDR_28(0x11000/4)
+#define NVRAM_DUAL_FCP_NVME_FLAG_OFFSET0x196
+
#endif
diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c
index fc6e12fb7d77..ae13aabf280b 100644
--- a/drivers/scsi/qla2xxx/qla_gs.c
+++ b/drivers/scsi/qla2xxx/qla_gs.c
@@ -248,7 +248,7 @@ qla2x00_ga_nxt(scsi_qla_host_t *vha, fc_port_t *fcport)
WWN_SIZE);
fcport->fc4_type = (ct_rsp->rsp.ga_nxt.fc4_types[2] & BIT_0) ?
- FC4_TYPE_FCP_SCSI : FC4_TYPE_OTHER;
+ FS_FC4TYPE_FCP : FC4_TYPE_OTHER;
if (ct_rsp->rsp.ga_nxt.port_type != NS_N_PORT_TYPE &&
ct_rsp->rsp.ga_nxt.port_type != NS_NL_PORT_TYPE)
@@ -2887,7 +2887,7 @@ qla2x00_gff_id(scsi_qla_host_t *vha, sw_info_t *list)
struct ct_sns_req *ct_req;
struct ct_sns_rsp *ct_rsp;
struct qla_hw_data *ha = vha->hw;
- uint8_t fcp_scsi_features = 0;
+ uint8_t fcp_scsi_features = 0, nvme_features = 0;
struct ct_arg arg;
for (i = 0; i < ha->max_fibre_devices; i++) {
@@ -2933,14 +2933,19 @@ qla2x00_gff_id(scsi_qla_host_t *vha, sw_info_t *list)
ct_rsp->rsp.gff_id.fc4_features[GFF_FCP_SCSI_OFFSET];
fcp_scsi_features &= 0x0f;
- if (fcp_scsi_features)
- list[i].fc4_type = FC4_TYPE_FCP_SCSI;
- else
- list[i].fc4_type = FC4_TYPE_OTHER;
+ if (fcp_scsi_features) {
+ list[i].fc4_type = FS_FC4TYPE_FCP;
+ list[i].fc4_features = fcp_scsi_features;
+ }
- list[i].fc4f_nvme =
+
[PATCH 5.4 18/73] neighbour: Disregard DEAD dst in neigh_update
From: Tong Zhu
[ Upstream commit d47ec7a0a7271dda08932d6208e4ab65ab0c987c ]
After a short network outage, the dst_entry is timed out and put
in DST_OBSOLETE_DEAD. We are in this code because arp reply comes
from this neighbour after network recovers. There is a potential
race condition that dst_entry is still in DST_OBSOLETE_DEAD.
With that, another neighbour lookup causes more harm than good.
In best case all packets in arp_queue are lost. This is
counterproductive to the original goal of finding a better path
for those packets.
I observed a worst case with 4.x kernel where a dst_entry in
DST_OBSOLETE_DEAD state is associated with loopback net_device.
It leads to an ethernet header with all zero addresses.
A packet with all zero source MAC address is quite deadly with
mac80211, ath9k and 802.11 block ack. It fails
ieee80211_find_sta_by_ifaddr in ath9k (xmit.c). Ath9k flushes tx
queue (ath_tx_complete_aggr). BAW (block ack window) is not
updated. BAW logic is damaged and ath9k transmission is disabled.
Signed-off-by: Tong Zhu
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
net/core/neighbour.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 7080d708b7d0..6635b83113f8 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1379,7 +1379,7 @@ static int __neigh_update(struct neighbour *neigh, const
u8 *lladdr,
* we can reinject the packet there.
*/
n2 = NULL;
- if (dst) {
+ if (dst && dst->obsolete != DST_OBSOLETE_DEAD) {
n2 = dst_neigh_lookup_skb(dst, skb);
if (n2)
n1 = n2;
--
2.30.2
[PATCH 5.4 16/73] arc: kernel: Return -EFAULT if copy_to_user() fails
From: Wang Qing [ Upstream commit 46e152186cd89d940b26726fff11eb3f4935b45a ] The copy_to_user() function returns the number of bytes remaining to be copied, but we want to return -EFAULT if the copy doesn't complete. Signed-off-by: Wang Qing Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/kernel/signal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arc/kernel/signal.c b/arch/arc/kernel/signal.c index 3d57ed0d8535..404518051093 100644 --- a/arch/arc/kernel/signal.c +++ b/arch/arc/kernel/signal.c @@ -96,7 +96,7 @@ stash_usr_regs(struct rt_sigframe __user *sf, struct pt_regs *regs, sizeof(sf->uc.uc_mcontext.regs.scratch)); err |= __copy_to_user(&sf->uc.uc_sigmask, set, sizeof(sigset_t)); - return err; + return err ? -EFAULT : 0; } static int restore_usr_regs(struct pt_regs *regs, struct rt_sigframe __user *sf) @@ -110,7 +110,7 @@ static int restore_usr_regs(struct pt_regs *regs, struct rt_sigframe __user *sf) &(sf->uc.uc_mcontext.regs.scratch), sizeof(sf->uc.uc_mcontext.regs.scratch)); if (err) - return err; + return -EFAULT; set_current_blocked(&set); regs->bta = uregs.scratch.bta; -- 2.30.2
[PATCH 5.4 36/73] net/rds: Avoid potential use after free in rds_send_remove_from_sock
From: Aditya Pakki [ Upstream commit 0c85a7e87465f2d4cbc768e245f4f45b2f299b05 ] In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource is freed and later under spinlock, causing potential use-after-free. Set the free pointer to NULL to avoid undefined behavior. Signed-off-by: Aditya Pakki Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- net/rds/message.c | 1 + net/rds/send.c| 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/net/rds/message.c b/net/rds/message.c index 92b6b22884d4..ed1d2255ce5a 100644 --- a/net/rds/message.c +++ b/net/rds/message.c @@ -180,6 +180,7 @@ void rds_message_put(struct rds_message *rm) rds_message_purge(rm); kfree(rm); + rm = NULL; } } EXPORT_SYMBOL_GPL(rds_message_put); diff --git a/net/rds/send.c b/net/rds/send.c index 68e2bdb08fd0..aa3bc081773f 100644 --- a/net/rds/send.c +++ b/net/rds/send.c @@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head *messages, int status) unlock_and_drop: spin_unlock_irqrestore(&rm->m_rs_lock, flags); rds_message_put(rm); - if (was_on_sock) + if (was_on_sock && rm) rds_message_put(rm); } -- 2.30.2
[PATCH 5.4 40/73] Input: s6sy761 - fix coordinate read bit shift
From: Caleb Connolly
commit 30b3f68715595dee7fe4d9bd91a2252c3becdf0a upstream.
The touch coordinate register contains the following:
byte 3 byte 2 byte 1
+++ +-+ +-+
||| | | | |
| X[3:0] | Y[3:0] | | Y[11:4] | | X[11:4] |
||| | | | |
+++ +-+ +-+
Bytes 2 and 1 need to be shifted left by 4 bits, the least significant
nibble of each is stored in byte 3. Currently they are only
being shifted by 3 causing the reported coordinates to be incorrect.
This matches downstream examples, and has been confirmed on my
device (OnePlus 7 Pro).
Fixes: 0145a7141e59 ("Input: add support for the Samsung S6SY761 touchscreen")
Signed-off-by: Caleb Connolly
Reviewed-by: Andi Shyti
Link: https://lore.kernel.org/r/20210305185710.225168-1-ca...@connolly.tech
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/touchscreen/s6sy761.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/input/touchscreen/s6sy761.c
+++ b/drivers/input/touchscreen/s6sy761.c
@@ -145,8 +145,8 @@ static void s6sy761_report_coordinates(s
u8 major = event[4];
u8 minor = event[5];
u8 z = event[6] & S6SY761_MASK_Z;
- u16 x = (event[1] << 3) | ((event[3] & S6SY761_MASK_X) >> 4);
- u16 y = (event[2] << 3) | (event[3] & S6SY761_MASK_Y);
+ u16 x = (event[1] << 4) | ((event[3] & S6SY761_MASK_X) >> 4);
+ u16 y = (event[2] << 4) | (event[3] & S6SY761_MASK_Y);
input_mt_slot(sdata->input, tid);
