Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update atyfb_base.c #441

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update atyfb_base.c #441

wants to merge 1 commit into from

Conversation

sohu0106
Copy link
Contributor

Structure atyclk is copied to userland with padding bytes after
"vclk_post_div" field unitialized. It leads to leaking of
contents of kernel stack memory. We have to initialize them to zero. or it will allows local users to obtain potentially sensitive information from kernel stack memory by reading a copy of this structure

Structure atyclk is copied to userland with padding bytes after
"vclk_post_div" field unitialized.  It leads to leaking of
contents of kernel stack memory.  We have to initialize them to zero. or it will allows local users to obtain potentially sensitive information from kernel stack memory by reading a copy of this structure
@KernelPRBot
Copy link

Hi @sohu0106!

Thanks for your contribution to the Linux kernel!

Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.

Sending patches isn't quite as simple as sending a pull request, but fortunately it is a well documented process.

Here's what to do:

  • Format your contribution according to kernel requirements
  • Decide who to send your contribution to
  • Set up your system to send your contribution as an email
  • Send your contribution and wait for feedback

How do I format my contribution?

The Linux kernel community is notoriously picky about how contributions are formatted and sent. Fortunately, they have documented their expectations.

Firstly, all contributions need to be formatted as patches. A patch is a plain text document showing the change you want to make to the code, and documenting why it is a good idea.

You can create patches with git format-patch.

Secondly, patches need 'commit messages', which is the human-friendly documentation explaining what the change is and why it's necessary.

Thirdly, changes have some technical requirements. There is a Linux kernel coding style, and there are licensing requirements you need to comply with.

Both of these are documented in the Submitting Patches documentation that is part of the kernel.

Note that you will almost certainly have to modify your existing git commits to satisfy these requirements. Don't worry: there are many guides on the internet for doing this.

Who do I send my contribution to?

The Linux kernel is composed of a number of subsystems. These subsystems are maintained by different people, and have different mailing lists where they discuss proposed changes.

If you don't already know what subsystem your change belongs to, the get_maintainer.pl script in the kernel source can help you.

get_maintainer.pl will take the patch or patches you created in the previous step, and tell you who is responsible for them, and what mailing lists are used. You can also take a look at the MAINTAINERS file by hand.

Make sure that your list of recipients includes a mailing list. If you can't find a more specific mailing list, then LKML - the Linux Kernel Mailing List - is the place to send your patches.

It's not usually necessary to subscribe to the mailing list before you send the patches, but if you're interested in kernel development, subscribing to a subsystem mailing list is a good idea. (At this point, you probably don't need to subscribe to LKML - it is a very high traffic list with about a thousand messages per day, which is often not useful for beginners.)

How do I send my contribution?

Use git send-email, which will ensure that your patches are formatted in the standard manner. In order to use git send-email, you'll need to configure git to use your SMTP email server.

For more information about using git send-email, look at the Git documentation or type git help send-email. There are a number of useful guides and tutorials about git send-email that can be found on the internet.

How do I get help if I'm stuck?

Firstly, don't get discouraged! There are an enormous number of resources on the internet, and many kernel developers who would like to see you succeed.

Many issues - especially about how to use certain tools - can be resolved by using your favourite internet search engine.

If you can't find an answer, there are a few places you can turn:

  • Kernel Newbies - this website contains a lot of useful resources for new kernel developers.
  • If you'd like a step-by-step, challenge-based introduction to kernel development, the Eudyptula Challenge would be an excellent start.
  • The kernel documentation - see also the Documentation directory in the kernel tree.

If you get really, really stuck, you could try the owners of this bot, @daxtens and @ajdlinux. Please be aware that we do have full-time jobs, so we are almost certainly the slowest way to get answers!

I sent my patch - now what?

You wait.

You can check that your email has been received by checking the mailing list archives for the mailing list you sent your patch to. Messages may not be received instantly, so be patient. Kernel developers are generally very busy people, so it may take a few weeks before your patch is looked at.

Then, you keep waiting. Three things may happen:

  • You might get a response to your email. Often these will be comments, which may require you to make changes to your patch, or explain why your way is the best way. You should respond to these comments, and you may need to submit another revision of your patch to address the issues raised.
  • Your patch might be merged into the subsystem tree. Code that becomes part of Linux isn't merged into the main repository straight away - it first goes into the subsystem tree, which is managed by the subsystem maintainer. It is then batched up with a number of other changes sent to Linus for inclusion. (This process is described in some detail in the kernel development process guide).
  • Your patch might be ignored completely. This happens sometimes - don't take it personally. Here's what to do:
    • Wait a bit more - patches often take several weeks to get a response; more if they were sent at a busy time.
    • Kernel developers often silently ignore patches that break the rules. Check for obvious violations of the the Submitting Patches guidelines, the style guidelines, and any other documentation you can find about your subsystem. Check that you're sending your patch to the right place.
    • Try again later. When you resend it, don't add angry commentary, as that will get your patch ignored. It might also get you silently blacklisted.

Further information

Happy hacking!

This message was posted by a bot - if you have any questions or suggestions, please talk to my owners, @ajdlinux and @daxtens, or raise an issue at https://github.com/ajdlinux/KernelPRBot.

fengguang pushed a commit to 0day-ci/linux that referenced this pull request Aug 31, 2017
'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
bzolnier pushed a commit to bzolnier/linux that referenced this pull request Sep 4, 2017
'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
vstehle pushed a commit to vstehle/linux that referenced this pull request Sep 20, 2017
… to userspace

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

BUG=chromium:762904
TEST=Build and run

Change-Id: I414c8ad7057bfb560bfd15d5342e45e4ea0edb52
References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 8e75f7a)
Reviewed-on: https://chromium-review.googlesource.com/673347
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
ahmedradaideh pushed a commit to ahmedradaideh/OnePlus3T that referenced this pull request Oct 3, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
scafroglia93 pushed a commit to HardcoreKernel/bardock that referenced this pull request Oct 3, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scafroglia93 pushed a commit to HardcoreKernel/freezerfhd that referenced this pull request Oct 3, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ahmedradaideh pushed a commit to ahmedradaideh/OnePlus3T that referenced this pull request Oct 3, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
ahmedradaideh pushed a commit to ahmedradaideh/OnePlus3T that referenced this pull request Oct 3, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
ahmedradaideh pushed a commit to ahmedradaideh/OnePlus3T that referenced this pull request Oct 3, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
ahmedradaideh pushed a commit to ahmedradaideh/OnePlus3T that referenced this pull request Oct 3, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
ahmedradaideh pushed a commit to ahmedradaideh/OnePlus3T that referenced this pull request Oct 4, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
woodsts pushed a commit to woodsts/linux-stable that referenced this pull request Oct 5, 2017
commit 8e75f7a upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
woodsts pushed a commit to woodsts/linux-stable that referenced this pull request Oct 5, 2017
commit 8e75f7a upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nathanchance pushed a commit to nathanchance/op5 that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
woodsts pushed a commit to woodsts/linux-stable that referenced this pull request Oct 5, 2017
commit 8e75f7a upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
woodsts pushed a commit to woodsts/linux-stable that referenced this pull request Oct 5, 2017
commit 8e75f7a upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nathanchance pushed a commit to upstream-caf-kernels/msm-3.18 that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nathanchance pushed a commit to upstream-caf-kernels/msm-3.18 that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nathanchance pushed a commit to upstream-caf-kernels/msm-4.4 that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
freak07 pushed a commit to freak07/Kirisakura_msm8998_EAS_CAF that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit b188b51c98c5ffecc59978f0098c6c28b4313220)
msfjarvis pushed a commit to msfjarvis/oneplus3 that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
RiteshSaxena pushed a commit to RiteshSaxena/android_kernel_xiaomi_msm8937 that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scafroglia93 pushed a commit to HardcoreKernel/bardock that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scafroglia93 pushed a commit to HardcoreKernel/freezerfhd that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bibahR pushed a commit to jancokOS/android_kernel_xiaomi_msm8996 that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ahmedradaideh pushed a commit to ahmedradaideh/OnePlus3T that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
Adesh15 pushed a commit to Adesh15/android_kernel_xiaomi_msm8953 that referenced this pull request Oct 5, 2017
commit 8e75f7a upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ahmedradaideh pushed a commit to ahmedradaideh/OnePlus3T that referenced this pull request Oct 5, 2017
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
Noltari pushed a commit to Noltari/linux that referenced this pull request Sep 10, 2019
[ Upstream commit af8a85a ]

Calling ceph_buffer_put() in fill_inode() may result in freeing the
i_xattrs.blob buffer while holding the i_ceph_lock.  This can be fixed by
postponing the call until later, when the lock is released.

The following backtrace was triggered by fstests generic/070.

  BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
  in_atomic(): 1, irqs_disabled(): 0, pid: 3852, name: kworker/0:4
  6 locks held by kworker/0:4/3852:
   #0: 000000004270f6bb ((wq_completion)ceph-msgr){+.+.}, at: process_one_work+0x1b8/0x5f0
   #1: 00000000eb420803 ((work_completion)(&(&con->work)->work)){+.+.}, at: process_one_work+0x1b8/0x5f0
   #2: 00000000be1c53a4 (&s->s_mutex){+.+.}, at: dispatch+0x288/0x1476
   #3: 00000000559cb958 (&mdsc->snap_rwsem){++++}, at: dispatch+0x2eb/0x1476
   #4: 000000000d5ebbae (&req->r_fill_mutex){+.+.}, at: dispatch+0x2fc/0x1476
   #5: 00000000a83d0514 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: fill_inode.isra.0+0xf8/0xf70
  CPU: 0 PID: 3852 Comm: kworker/0:4 Not tainted 5.2.0+ torvalds#441
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
  Workqueue: ceph-msgr ceph_con_workfn
  Call Trace:
   dump_stack+0x67/0x90
   ___might_sleep.cold+0x9f/0xb1
   vfree+0x4b/0x60
   ceph_buffer_release+0x1b/0x60
   fill_inode.isra.0+0xa9b/0xf70
   ceph_fill_trace+0x13b/0xc70
   ? dispatch+0x2eb/0x1476
   dispatch+0x320/0x1476
   ? __mutex_unlock_slowpath+0x4d/0x2a0
   ceph_con_workfn+0xc97/0x2ec0
   ? process_one_work+0x1b8/0x5f0
   process_one_work+0x244/0x5f0
   worker_thread+0x4d/0x3e0
   kthread+0x105/0x140
   ? process_one_work+0x5f0/0x5f0
   ? kthread_park+0x90/0x90
   ret_from_fork+0x3a/0x50

Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
shenki pushed a commit to openbmc/linux that referenced this pull request Sep 10, 2019
[ Upstream commit af8a85a ]

Calling ceph_buffer_put() in fill_inode() may result in freeing the
i_xattrs.blob buffer while holding the i_ceph_lock.  This can be fixed by
postponing the call until later, when the lock is released.

The following backtrace was triggered by fstests generic/070.

  BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
  in_atomic(): 1, irqs_disabled(): 0, pid: 3852, name: kworker/0:4
  6 locks held by kworker/0:4/3852:
   #0: 000000004270f6bb ((wq_completion)ceph-msgr){+.+.}, at: process_one_work+0x1b8/0x5f0
   #1: 00000000eb420803 ((work_completion)(&(&con->work)->work)){+.+.}, at: process_one_work+0x1b8/0x5f0
   #2: 00000000be1c53a4 (&s->s_mutex){+.+.}, at: dispatch+0x288/0x1476
   #3: 00000000559cb958 (&mdsc->snap_rwsem){++++}, at: dispatch+0x2eb/0x1476
   #4: 000000000d5ebbae (&req->r_fill_mutex){+.+.}, at: dispatch+0x2fc/0x1476
   #5: 00000000a83d0514 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: fill_inode.isra.0+0xf8/0xf70
  CPU: 0 PID: 3852 Comm: kworker/0:4 Not tainted 5.2.0+ torvalds#441
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
  Workqueue: ceph-msgr ceph_con_workfn
  Call Trace:
   dump_stack+0x67/0x90
   ___might_sleep.cold+0x9f/0xb1
   vfree+0x4b/0x60
   ceph_buffer_release+0x1b/0x60
   fill_inode.isra.0+0xa9b/0xf70
   ceph_fill_trace+0x13b/0xc70
   ? dispatch+0x2eb/0x1476
   dispatch+0x320/0x1476
   ? __mutex_unlock_slowpath+0x4d/0x2a0
   ceph_con_workfn+0xc97/0x2ec0
   ? process_one_work+0x1b8/0x5f0
   process_one_work+0x244/0x5f0
   worker_thread+0x4d/0x3e0
   kthread+0x105/0x140
   ? process_one_work+0x5f0/0x5f0
   ? kthread_park+0x90/0x90
   ret_from_fork+0x3a/0x50

Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
johnhubbard pushed a commit to johnhubbard/linux that referenced this pull request Sep 25, 2019
GIT 361469211f876e67d7ca3d3d29e6d1c3e313d0f1

commit 7837951a12fdaf88d2c51ff0757980c00072790c
Author: Dave Airlie <airlied@redhat.com>
Date:   Sat Aug 24 15:07:07 2019 +1000

    drm/mediatek: include dma-mapping header
    
    Although it builds fine here in my arm cross compile, it seems
    either via some other patches in -next or some Kconfig combination,
    this fails to build for everyone.
    
    Include linux/dma-mapping.h should fix it.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit 2e16f3e926ed48373c98edea85c6ad0ef69425d1
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Fri Aug 23 11:34:16 2019 +0100

    KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity
    
    At the moment we initialise the target *mask* of a virtual IRQ to the
    VCPU it belongs to, even though this mask is only defined for GICv2 and
    quickly runs out of bits for many GICv3 guests.
    This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
    ------
    [ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
    [ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
    ------
    Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
    dump is wrong, due to this very same problem.
    
    Because there is no requirement to create the VGIC device before the
    VCPUs (and QEMU actually does it the other way round), we can't safely
    initialise mpidr or targets in kvm_vgic_vcpu_init(). But since we touch
    every private IRQ for each VCPU anyway later (in vgic_init()), we can
    just move the initialisation of those fields into there, where we
    definitely know the VGIC type.
    
    On the way make sure we really have either a VGICv2 or a VGICv3 device,
    since the existing code is just checking for "VGICv3 or not", silently
    ignoring the uninitialised case.
    
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Reported-by: Dave Martin <dave.martin@arm.com>
    Tested-by: Julien Grall <julien.grall@arm.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>

commit c536277e0db1ad2e9fbb9dfd940c3565a14d9c52
Author: Bernard Metzler <bmt@zurich.ibm.com>
Date:   Thu Aug 22 19:37:38 2019 +0200

    RDMA/siw: Fix 64/32bit pointer inconsistency
    
    Fixes improper casting between addresses and unsigned types.
    Changes siw_pbl_get_buffer() function to return appropriate
    dma_addr_t, and not u64.
    
    Also fixes debug prints. Now any potentially kernel private
    pointers are printed formatted as '%pK', to allow keeping that
    information secret.
    
    Fixes: d941bfe500be ("RDMA/siw: Change CQ flags from 64->32 bits")
    Fixes: b0fff7317bb4 ("rdma/siw: completion queue methods")
    Fixes: 8b6a361b8c48 ("rdma/siw: receive path")
    Fixes: b9be6f18cf9e ("rdma/siw: transmit path")
    Fixes: f29dd55b0236 ("rdma/siw: queue pair methods")
    Fixes: 2251334dcac9 ("rdma/siw: application buffer management")
    Fixes: 303ae1cdfdf7 ("rdma/siw: application interface")
    Fixes: 6c52fdc244b5 ("rdma/siw: connection management")
    Fixes: a531975279f3 ("rdma/siw: main include file")
    
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Reported-by: Jason Gunthorpe <jgg@ziepe.ca>
    Reported-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Bernard Metzler <bmt@zurich.ibm.com>
    Link: https://lore.kernel.org/r/20190822173738.26817-1-bmt@zurich.ibm.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 1cfd5d3399e87167b7f9157ef99daa0e959f395d
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Aug 23 09:54:09 2019 -0400

    dm table: fix invalid memory accesses with too high sector number
    
    If the sector number is too high, dm_table_find_target() should return a
    pointer to a zeroed dm_target structure (the caller should test it with
    dm_target_is_valid).
    
    However, for some table sizes, the code in dm_table_find_target() that
    performs btree lookup will access out of bound memory structures.
    
    Fix this bug by testing the sector number at the beginning of
    dm_table_find_target(). Also, add an "inline" keyword to the function
    dm_table_get_size() because this is a hot path.
    
    Fixes: 512875bd9661 ("dm: table detect io beyond device")
    Cc: stable@vger.kernel.org
    Reported-by: Zhang Tao <kontais@zoho.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 1fb254aa983bf190cfd685d40c64a480a9bafaee
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Thu Aug 22 20:55:54 2019 -0700

    xfs: fix missing ILOCK unlock when xfs_setattr_nonsize fails due to EDQUOT
    
    Benjamin Moody reported to Debian that XFS partially wedges when a chgrp
    fails on account of being out of disk quota.  I ran his reproducer
    script:
    
    # adduser dummy
    # adduser dummy plugdev
    
    # dd if=/dev/zero bs=1M count=100 of=test.img
    # mkfs.xfs test.img
    # mount -t xfs -o gquota test.img /mnt
    # mkdir -p /mnt/dummy
    # chown -c dummy /mnt/dummy
    # xfs_quota -xc 'limit -g bsoft=100k bhard=100k plugdev' /mnt
    
    (and then as user dummy)
    
    $ dd if=/dev/urandom bs=1M count=50 of=/mnt/dummy/foo
    $ chgrp plugdev /mnt/dummy/foo
    
    and saw:
    
    ================================================
    WARNING: lock held when returning to user space!
    5.3.0-rc5 #rc5 Tainted: G        W
    ------------------------------------------------
    chgrp/47006 is leaving the kernel with locks still held!
    1 lock held by chgrp/47006:
     #0: 000000006664ea2d (&xfs_nondir_ilock_class){++++}, at: xfs_ilock+0xd2/0x290 [xfs]
    
    ...which is clearly caused by xfs_setattr_nonsize failing to unlock the
    ILOCK after the xfs_qm_vop_chown_reserve call fails.  Add the missing
    unlock.
    
    Reported-by: benjamin.moody@gmail.com
    Fixes: 253f4911f297 ("xfs: better xfs_trans_alloc interface")
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>

commit c358ebf59634f06d8ed176da651ec150df3c8686
Author: Lyude Paul <lyude@redhat.com>
Date:   Thu Jul 25 15:40:01 2019 -0400

    drm/nouveau: Don't retry infinitely when receiving no data on i2c over AUX
    
    While I had thought I had fixed this issue in:
    
    commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
    ->fini()")
    
    It turns out that while I did fix the error messages I was seeing on my
    P50 when trying to access i2c busses with the GPU in runtime suspend, I
    accidentally had missed one important detail that was mentioned on the
    bug report this commit was supposed to fix: that the CPU would only lock
    up when trying to access i2c busses _on connected devices_ _while the
    GPU is not in runtime suspend_. Whoops. That definitely explains why I
    was not able to get my machine to hang with i2c bus interactions until
    now, as plugging my P50 into it's dock with an HDMI monitor connected
    allowed me to finally reproduce this locally.
    
    Now that I have managed to reproduce this issue properly, it looks like
    the problem is much simpler then it looks. It turns out that some
    connected devices, such as MST laptop docks, will actually ACK i2c reads
    even if no data was actually read:
    
    [  275.063043] nouveau 0000:01:00.0: i2c: aux 000a: 1: 0000004c 1
    [  275.063447] nouveau 0000:01:00.0: i2c: aux 000a: 00 01101000 10040000
    [  275.063759] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000001
    [  275.064024] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
    [  275.064285] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
    [  275.064594] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
    
    Because we don't handle the situation of i2c ack without any data, we
    end up entering an infinite loop in nvkm_i2c_aux_i2c_xfer() since the
    value of cnt always remains at 0. This finally properly explains how
    this could result in a CPU hang like the ones observed in the
    aforementioned commit.
    
    So, fix this by retrying transactions if no data is written or received,
    and give up and fail the transaction if we continue to not write or
    receive any data after 32 retries.
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

commit 75710f08ea7e41b2f7010da3f6deab061f7a853b
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Wed Aug 21 22:25:27 2019 -0500

    drm/amdgpu/powerplay: silence a warning in smu_v11_0_setup_pptable
    
    I think gcc is confused as I don't see how size could be used
    unitialized, but go ahead and silence the warning.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190822032527.1376-1-alexander.deucher@amd.com

commit 08f5439f1df25a6cf6cf4c72cf6c13025599ce67
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Aug 21 22:19:11 2019 -0600

    io_uring: add need_resched() check in inner poll loop
    
    The outer poll loop checks for whether we need to reschedule, and
    returns to userspace if we do. However, it's possible to get stuck
    in the inner loop as well, if the CPU we are running on needs to
    reschedule to finish the IO work.
    
    Add the need_resched() check in the inner loop as well. This fixes
    a potential hang if the kernel is configured with
    CONFIG_PREEMPT_VOLUNTARY=y.
    
    Reported-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Tested-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit ae148243d3f0816b37477106c05a2ec7d5f32614
Author: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Date:   Mon Aug 19 11:31:21 2019 +0800

    dm space map metadata: fix missing store of apply_bops() return value
    
    In commit 6096d91af0b6 ("dm space map metadata: fix occasional leak
    of a metadata block on resize"), we refactor the commit logic to a new
    function 'apply_bops'.  But when that logic was replaced in out() the
    return value was not stored.  This may lead out() returning a wrong
    value to the caller.
    
    Fixes: 6096d91af0b6 ("dm space map metadata: fix occasional leak of a metadata block on resize")
    Cc: stable@vger.kernel.org
    Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit e4f9d6013820d1eba1432d51dd1c5795759aa77f
Author: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Date:   Sat Aug 17 13:32:40 2019 +0800

    dm btree: fix order of block initialization in btree_split_beneath
    
    When btree_split_beneath() splits a node to two new children, it will
    allocate two blocks: left and right.  If right block's allocation
    failed, the left block will be unlocked and marked dirty.  If this
    happened, the left block'ss content is zero, because it wasn't
    initialized with the btree struct before the attempot to allocate the
    right block.  Upon return, when flushing the left block to disk, the
    validator will fail when check this block.  Then a BUG_ON is raised.
    
    Fix this by completely initializing the left block before allocating and
    initializing the right block.
    
    Fixes: 4dcb8b57df359 ("dm btree: fix leak of bufio-backed block in btree_split_beneath error path")
    Cc: stable@vger.kernel.org
    Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit fab4f97e1fe33cf08e58c09cf9eee334857d9fe7
Author: Bernard Metzler <bmt@zurich.ibm.com>
Date:   Thu Aug 22 17:07:41 2019 +0200

    RDMA/siw: Fix SGL mapping issues
    
    All user level and most in-kernel applications submit WQEs
    where the SG list entries are all of a single type.
    iSER in particular, however, will send us WQEs with mixed SG
    types: sge[0] = kernel buffer, sge[1] = PBL region.
    Check and set is_kva on each SG entry individually instead of
    assuming the first SGE type carries through to the last.
    This fixes iSER over siw.
    
    Fixes: b9be6f18cf9e ("rdma/siw: transmit path")
    Reported-by: Krishnamraju Eraparaju <krishna2@chelsio.com>
    Tested-by: Krishnamraju Eraparaju <krishna2@chelsio.com>
    Signed-off-by: Bernard Metzler <bmt@zurich.ibm.com>
    Link: https://lore.kernel.org/r/20190822150741.21871-1-bmt@zurich.ibm.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit d37b1e534071ab1983e7c85273234b132c77591a
Author: Selvin Xavier <selvin.xavier@broadcom.com>
Date:   Thu Aug 22 03:02:50 2019 -0700

    RDMA/bnxt_re: Fix stack-out-of-bounds in bnxt_qplib_rcfw_send_message
    
    Driver copies FW commands to the HW queue as  units of 16 bytes. Some
    of the command structures are not exact multiple of 16. So while copying
    the data from those structures, the stack out of bounds messages are
    reported by KASAN. The following error is reported.
    
    [ 1337.530155] ==================================================================
    [ 1337.530277] BUG: KASAN: stack-out-of-bounds in bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
    [ 1337.530413] Read of size 16 at addr ffff888725477a48 by task rmmod/2785
    
    [ 1337.530540] CPU: 5 PID: 2785 Comm: rmmod Tainted: G           OE     5.2.0-rc6+ #75
    [ 1337.530541] Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.0.4 08/28/2014
    [ 1337.530542] Call Trace:
    [ 1337.530548]  dump_stack+0x5b/0x90
    [ 1337.530556]  ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
    [ 1337.530560]  print_address_description+0x65/0x22e
    [ 1337.530568]  ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
    [ 1337.530575]  ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
    [ 1337.530577]  __kasan_report.cold.3+0x37/0x77
    [ 1337.530581]  ? _raw_write_trylock+0x10/0xe0
    [ 1337.530588]  ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
    [ 1337.530590]  kasan_report+0xe/0x20
    [ 1337.530592]  memcpy+0x1f/0x50
    [ 1337.530600]  bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
    [ 1337.530608]  ? bnxt_qplib_creq_irq+0xa0/0xa0 [bnxt_re]
    [ 1337.530611]  ? xas_create+0x3aa/0x5f0
    [ 1337.530613]  ? xas_start+0x77/0x110
    [ 1337.530615]  ? xas_clear_mark+0x34/0xd0
    [ 1337.530623]  bnxt_qplib_free_mrw+0x104/0x1a0 [bnxt_re]
    [ 1337.530631]  ? bnxt_qplib_destroy_ah+0x110/0x110 [bnxt_re]
    [ 1337.530633]  ? bit_wait_io_timeout+0xc0/0xc0
    [ 1337.530641]  bnxt_re_dealloc_mw+0x2c/0x60 [bnxt_re]
    [ 1337.530648]  bnxt_re_destroy_fence_mr+0x77/0x1d0 [bnxt_re]
    [ 1337.530655]  bnxt_re_dealloc_pd+0x25/0x60 [bnxt_re]
    [ 1337.530677]  ib_dealloc_pd_user+0xbe/0xe0 [ib_core]
    [ 1337.530683]  srpt_remove_one+0x5de/0x690 [ib_srpt]
    [ 1337.530689]  ? __srpt_close_all_ch+0xc0/0xc0 [ib_srpt]
    [ 1337.530692]  ? xa_load+0x87/0xe0
    ...
    [ 1337.530840]  do_syscall_64+0x6d/0x1f0
    [ 1337.530843]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 1337.530845] RIP: 0033:0x7ff5b389035b
    [ 1337.530848] Code: 73 01 c3 48 8b 0d 2d 0b 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fd 0a 2c 00 f7 d8 64 89 01 48
    [ 1337.530849] RSP: 002b:00007fff83425c28 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
    [ 1337.530852] RAX: ffffffffffffffda RBX: 00005596443e6750 RCX: 00007ff5b389035b
    [ 1337.530853] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005596443e67b8
    [ 1337.530854] RBP: 0000000000000000 R08: 00007fff83424ba1 R09: 0000000000000000
    [ 1337.530856] R10: 00007ff5b3902960 R11: 0000000000000206 R12: 00007fff83425e50
    [ 1337.530857] R13: 00007fff8342673c R14: 00005596443e6260 R15: 00005596443e6750
    
    [ 1337.530885] The buggy address belongs to the page:
    [ 1337.530962] page:ffffea001c951dc0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0
    [ 1337.530964] flags: 0x57ffffc0000000()
    [ 1337.530967] raw: 0057ffffc0000000 0000000000000000 ffffffff1c950101 0000000000000000
    [ 1337.530970] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    [ 1337.530970] page dumped because: kasan: bad access detected
    
    [ 1337.530996] Memory state around the buggy address:
    [ 1337.531072]  ffff888725477900: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 f2 f2 f2
    [ 1337.531180]  ffff888725477980: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
    [ 1337.531288] >ffff888725477a00: 00 f2 f2 f2 f2 f2 f2 00 00 00 f2 00 00 00 00 00
    [ 1337.531393]                                                  ^
    [ 1337.531478]  ffff888725477a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [ 1337.531585]  ffff888725477b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [ 1337.531691] ==================================================================
    
    Fix this by passing the exact size of each FW command to
    bnxt_qplib_rcfw_send_message as req->cmd_size. Before sending
    the command to HW, modify the req->cmd_size to number of 16 byte units.
    
    Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver")
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/1566468170-489-1-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 7533be858f5b9a036b9f91556a3ed70786abca8e
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Mon Aug 19 16:05:31 2019 +0100

    afs: use correct afs_call_type in yfs_fs_store_opaque_acl2
    
    It seems that 'yfs_RXYFSStoreOpaqueACL2' should be use in
    yfs_fs_store_opaque_acl2().
    
    Fixes: f5e4546347bc ("afs: Implement YFS ACL setting")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David Howells <dhowells@redhat.com>

commit c4c613ff08d92e72bf64a65ec35a2c3aa1cfcd06
Author: Marc Dionne <marc.dionne@auristor.com>
Date:   Thu Aug 22 13:28:43 2019 +0100

    afs: Fix possible oops in afs_lookup trace event
    
    The afs_lookup trace event can cause the following:
    
    [  216.576777] BUG: kernel NULL pointer dereference, address: 000000000000023b
    [  216.576803] #PF: supervisor read access in kernel mode
    [  216.576813] #PF: error_code(0x0000) - not-present page
    ...
    [  216.576913] RIP: 0010:trace_event_raw_event_afs_lookup+0x9e/0x1c0 [kafs]
    
    If the inode from afs_do_lookup() is an error other than ENOENT, or if it
    is ENOENT and afs_try_auto_mntpt() returns an error, the trace event will
    try to dereference the error pointer as a valid pointer.
    
    Use IS_ERR_OR_NULL to only pass a valid pointer for the trace, or NULL.
    
    Ideally the trace would include the error value, but for now just avoid
    the oops.
    
    Fixes: 80548b03991f ("afs: Add more tracepoints")
    Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>

commit a5fb8e6c02d6a518fb2b1a2b8c2471fa77b69436
Author: David Howells <dhowells@redhat.com>
Date:   Thu Aug 22 13:28:43 2019 +0100

    afs: Fix leak in afs_lookup_cell_rcu()
    
    Fix a leak on the cell refcount in afs_lookup_cell_rcu() due to
    non-clearance of the default error in the case a NULL cell name is passed
    and the workstation default cell is used.
    
    Also put a bit at the end to make sure we don't leak a cell ref if we're
    going to be returning an error.
    
    This leak results in an assertion like the following when the kafs module is
    unloaded:
    
            AFS: Assertion failed
            2 == 1 is false
            0x2 == 0x1 is false
            ------------[ cut here ]------------
            kernel BUG at fs/afs/cell.c:770!
            ...
            RIP: 0010:afs_manage_cells+0x220/0x42f [kafs]
            ...
             process_one_work+0x4c2/0x82c
             ? pool_mayday_timeout+0x1e1/0x1e1
             ? do_raw_spin_lock+0x134/0x175
             worker_thread+0x336/0x4a6
             ? rescuer_thread+0x4af/0x4af
             kthread+0x1de/0x1ee
             ? kthread_park+0xd4/0xd4
             ret_from_fork+0x24/0x30
    
    Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
    Signed-off-by: David Howells <dhowells@redhat.com>

commit 2113c5f62b7423e4a72b890bd479704aa85c81ba
Author: Andrew Jones <drjones@redhat.com>
Date:   Thu Aug 22 13:03:05 2019 +0200

    KVM: arm/arm64: Only skip MMIO insn once
    
    If after an MMIO exit to userspace a VCPU is immediately run with an
    immediate_exit request, such as when a signal is delivered or an MMIO
    emulation completion is needed, then the VCPU completes the MMIO
    emulation and immediately returns to userspace. As the exit_reason
    does not get changed from KVM_EXIT_MMIO in these cases we have to
    be careful not to complete the MMIO emulation again, when the VCPU is
    eventually run again, because the emulation does an instruction skip
    (and doing too many skips would be a waste of guest code :-) We need
    to use additional VCPU state to track if the emulation is complete.
    As luck would have it, we already have 'mmio_needed', which even
    appears to be used in this way by other architectures already.
    
    Fixes: 0d640732dbeb ("arm64: KVM: Skip MMIO insn after emulation")
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Andrew Jones <drjones@redhat.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>

commit a561372405cf6bc6f14239b3a9e57bb39f2788b0
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Tue Aug 20 16:40:33 2019 +0200

    libceph: fix PG split vs OSD (re)connect race
    
    We can't rely on ->peer_features in calc_target() because it may be
    called both when the OSD session is established and open and when it's
    not.  ->peer_features is not valid unless the OSD session is open.  If
    this happens on a PG split (pg_num increase), that could mean we don't
    resend a request that should have been resent, hanging the client
    indefinitely.
    
    In userspace this was fixed by looking at require_osd_release and
    get_xinfo[osd].features fields of the osdmap.  However these fields
    belong to the OSD section of the osdmap, which the kernel doesn't
    decode (only the client section is decoded).
    
    Instead, let's drop this feature check.  It effectively checks for
    luminous, so only pre-luminous OSDs would be affected in that on a PG
    split the kernel might resend a request that should not have been
    resent.  Duplicates can occur in other scenarios, so both sides should
    already be prepared for them: see dup/replay logic on the OSD side and
    retry_attempt check on the client side.
    
    Cc: stable@vger.kernel.org
    Fixes: 7de030d6b10a ("libceph: resend on PG splits if OSD has RESEND_ON_SPLIT")
    Link: https://tracker.ceph.com/issues/41162
    Reported-by: Jerry Lee <leisurelysw24@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Tested-by: Jerry Lee <leisurelysw24@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>

commit 28a282616f56990547b9dcd5c6fbd2001344664c
Author: Jeff Layton <jlayton@kernel.org>
Date:   Thu Aug 15 06:23:38 2019 -0400

    ceph: don't try fill file_lock on unsuccessful GETFILELOCK reply
    
    When ceph_mdsc_do_request returns an error, we can't assume that the
    filelock_reply pointer will be set. Only try to fetch fields out of
    the r_reply_info when it returns success.
    
    Cc: stable@vger.kernel.org
    Reported-by: Hector Martin <hector@marcansoft.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit c95f1c5f436badb9bb87e9b30fd573f6b3d59423
Author: Erqi Chen <chenerqi@gmail.com>
Date:   Wed Jul 24 10:26:09 2019 +0800

    ceph: clear page dirty before invalidate page
    
    clear_page_dirty_for_io(page) before mapping->a_ops->invalidatepage().
    invalidatepage() clears page's private flag, if dirty flag is not
    cleared, the page may cause BUG_ON failure in ceph_set_page_dirty().
    
    Cc: stable@vger.kernel.org
    Link: https://tracker.ceph.com/issues/40862
    Signed-off-by: Erqi Chen <chenerqi@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit af8a85a41734f37b67ba8ce69d56b685bee4ac48
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:22 2019 +0100

    ceph: fix buffer free while holding i_ceph_lock in fill_inode()
    
    Calling ceph_buffer_put() in fill_inode() may result in freeing the
    i_xattrs.blob buffer while holding the i_ceph_lock.  This can be fixed by
    postponing the call until later, when the lock is released.
    
    The following backtrace was triggered by fstests generic/070.
    
      BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
      in_atomic(): 1, irqs_disabled(): 0, pid: 3852, name: kworker/0:4
      6 locks held by kworker/0:4/3852:
       #0: 000000004270f6bb ((wq_completion)ceph-msgr){+.+.}, at: process_one_work+0x1b8/0x5f0
       #1: 00000000eb420803 ((work_completion)(&(&con->work)->work)){+.+.}, at: process_one_work+0x1b8/0x5f0
       #2: 00000000be1c53a4 (&s->s_mutex){+.+.}, at: dispatch+0x288/0x1476
       #3: 00000000559cb958 (&mdsc->snap_rwsem){++++}, at: dispatch+0x2eb/0x1476
       #4: 000000000d5ebbae (&req->r_fill_mutex){+.+.}, at: dispatch+0x2fc/0x1476
       #5: 00000000a83d0514 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: fill_inode.isra.0+0xf8/0xf70
      CPU: 0 PID: 3852 Comm: kworker/0:4 Not tainted 5.2.0+ #441
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
      Workqueue: ceph-msgr ceph_con_workfn
      Call Trace:
       dump_stack+0x67/0x90
       ___might_sleep.cold+0x9f/0xb1
       vfree+0x4b/0x60
       ceph_buffer_release+0x1b/0x60
       fill_inode.isra.0+0xa9b/0xf70
       ceph_fill_trace+0x13b/0xc70
       ? dispatch+0x2eb/0x1476
       dispatch+0x320/0x1476
       ? __mutex_unlock_slowpath+0x4d/0x2a0
       ceph_con_workfn+0xc97/0x2ec0
       ? process_one_work+0x1b8/0x5f0
       process_one_work+0x244/0x5f0
       worker_thread+0x4d/0x3e0
       kthread+0x105/0x140
       ? process_one_work+0x5f0/0x5f0
       ? kthread_park+0x90/0x90
       ret_from_fork+0x3a/0x50
    
    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit 12fe3dda7ed89c95cc0ef7abc001ad1ad3e092f8
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:21 2019 +0100

    ceph: fix buffer free while holding i_ceph_lock in __ceph_build_xattrs_blob()
    
    Calling ceph_buffer_put() in __ceph_build_xattrs_blob() may result in
    freeing the i_xattrs.blob buffer while holding the i_ceph_lock.  This can
    be fixed by having this function returning the old blob buffer and have
    the callers of this function freeing it when the lock is released.
    
    The following backtrace was triggered by fstests generic/117.
    
      BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
      in_atomic(): 1, irqs_disabled(): 0, pid: 649, name: fsstress
      4 locks held by fsstress/649:
       #0: 00000000a7478e7e (&type->s_umount_key#19){++++}, at: iterate_supers+0x77/0xf0
       #1: 00000000f8de1423 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: ceph_check_caps+0x7b/0xc60
       #2: 00000000562f2b27 (&s->s_mutex){+.+.}, at: ceph_check_caps+0x3bd/0xc60
       #3: 00000000f83ce16a (&mdsc->snap_rwsem){++++}, at: ceph_check_caps+0x3ed/0xc60
      CPU: 1 PID: 649 Comm: fsstress Not tainted 5.2.0+ #439
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0x67/0x90
       ___might_sleep.cold+0x9f/0xb1
       vfree+0x4b/0x60
       ceph_buffer_release+0x1b/0x60
       __ceph_build_xattrs_blob+0x12b/0x170
       __send_cap+0x302/0x540
       ? __lock_acquire+0x23c/0x1e40
       ? __mark_caps_flushing+0x15c/0x280
       ? _raw_spin_unlock+0x24/0x30
       ceph_check_caps+0x5f0/0xc60
       ceph_flush_dirty_caps+0x7c/0x150
       ? __ia32_sys_fdatasync+0x20/0x20
       ceph_sync_fs+0x5a/0x130
       iterate_supers+0x8f/0xf0
       ksys_sync+0x4f/0xb0
       __ia32_sys_sync+0xa/0x10
       do_syscall_64+0x50/0x1c0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7fc6409ab617
    
    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit 86968ef21596515958d5f0a40233d02be78ecec0
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:20 2019 +0100

    ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()
    
    Calling ceph_buffer_put() in __ceph_setxattr() may end up freeing the
    i_xattrs.prealloc_blob buffer while holding the i_ceph_lock.  This can be
    fixed by postponing the call until later, when the lock is released.
    
    The following backtrace was triggered by fstests generic/117.
    
      BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
      in_atomic(): 1, irqs_disabled(): 0, pid: 650, name: fsstress
      3 locks held by fsstress/650:
       #0: 00000000870a0fe8 (sb_writers#8){.+.+}, at: mnt_want_write+0x20/0x50
       #1: 00000000ba0c4c74 (&type->i_mutex_dir_key#6){++++}, at: vfs_setxattr+0x55/0xa0
       #2: 000000008dfbb3f2 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: __ceph_setxattr+0x297/0x810
      CPU: 1 PID: 650 Comm: fsstress Not tainted 5.2.0+ #437
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0x67/0x90
       ___might_sleep.cold+0x9f/0xb1
       vfree+0x4b/0x60
       ceph_buffer_release+0x1b/0x60
       __ceph_setxattr+0x2b4/0x810
       __vfs_setxattr+0x66/0x80
       __vfs_setxattr_noperm+0x59/0xf0
       vfs_setxattr+0x81/0xa0
       setxattr+0x115/0x230
       ? filename_lookup+0xc9/0x140
       ? rcu_read_lock_sched_held+0x74/0x80
       ? rcu_sync_lockdep_assert+0x2e/0x60
       ? __sb_start_write+0x142/0x1a0
       ? mnt_want_write+0x20/0x50
       path_setxattr+0xba/0xd0
       __x64_sys_lsetxattr+0x24/0x30
       do_syscall_64+0x50/0x1c0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7ff23514359a
    
    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit 5c498950f730aa17c5f8a2cdcb903524e4002ed2
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:19 2019 +0100

    libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer
    
    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit 7035eef4496d95b69b0bc18e0bced09304e0afdf
Author: Song Liu <songliubraving@fb.com>
Date:   Wed Aug 21 11:45:25 2019 -0700

    md: update MAINTAINERS info
    
    I have been reviewing patches for md in the past few months. Mark me
    as the MD maintainer, as I have effectively been filling that role.
    
    Cc: NeilBrown <neilb@suse.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit ec6e491353b9024d4b1a65c48b21e3bc0faeae4e
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date:   Wed Aug 21 11:27:13 2019 -0400

    drm/amd/display: Calculate bpc based on max_requested_bpc
    
    [Why]
    The only place where state->max_bpc is updated on the connector is
    at the start of atomic check during drm_atomic_connector_check. It
    isn't updated when adding the connectors to the atomic state after
    the fact. It also doesn't necessarily reflect the right value when
    called in amdgpu during mode validation outside of atomic check.
    
    This can cause the wrong bpc to be used even if the max_requested_bpc
    is the correct value.
    
    [How]
    Don't rely on state->max_bpc reflecting the real bpc value and just
    do the min(...) based on display info bpc and max_requested_bpc.
    
    Fixes: 01933ba42d3d ("drm/amd/display: Use current connector state if NULL when checking bpc")
    Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Reviewed-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 1a701ea924815b0518733aa8d5d05c1f6fa87062
Author: Nicolai Hähnle <nicolai.haehnle@amd.com>
Date:   Tue Aug 20 15:39:53 2019 +0200

    drm/amdgpu: prevent memory leaks in AMDGPU_CS ioctl
    
    Error out if the AMDGPU_CS ioctl is called with multiple SYNCOBJ_OUT and/or
    TIMELINE_SIGNAL chunks, since otherwise the last chunk wins while the
    allocated array as well as the reference counts of sync objects are leaked.
    
    Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 221a2bdbd5d3871a5f41d912b2f06cc02e8f8b38
Author: Kenneth Feng <kenneth.feng@amd.com>
Date:   Tue Aug 20 15:11:37 2019 +0800

    drm/amd/amdgpu: disable MMHUB PG for navi10
    
    Disable MMHUB PG for navi10 according to the production requirement.
    
    Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 155f85c0d56896552439fd4fb5f43dfc4e9f842a
Author: Kevin Wang <kevin1.wang@amd.com>
Date:   Tue Aug 20 13:28:51 2019 +0800

    drm/amd/powerplay: remove duplicate macro smu_get_uclk_dpm_states in amdgpu_smu.h
    
    remove duplicate macro smu_get_uclk_dpm_states in amdgpu_smu.h
    
    "
     #define smu_get_uclk_dpm_states(smu, clocks_in_khz, num_states) \
             ((smu)->ppt_funcs->get_uclk_dpm_states ? (smu)->ppt_funcs->get_uclk_dpm_states((smu), (clocks_in_khz), (num_states)) : 0)
     #define smu_get_max_sustainable_clocks_by_dc(smu, max_clocks) \
             ((smu)->funcs->get_max_sustainable_clocks_by_dc ? (smu)->funcs->get_max_sustainable_clocks_by_dc((smu), (max_clocks)) : 0)
     #define smu_get_uclk_dpm_states(smu, clocks_in_khz, num_states) \
             ((smu)->ppt_funcs->get_uclk_dpm_states ? (smu)->ppt_funcs->get_uclk_dpm_states((smu), (clocks_in_khz), (num_states)) : 0)
    "
    
    Signed-off-by: Kevin Wang <kevin1.wang@amd.com>
    Reviewed-by: Huang Rui <ray.huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 00430144ff7343369222a110985aaa6726fb26e0
Author: Kevin Wang <kevin1.wang@amd.com>
Date:   Mon Aug 19 23:38:02 2019 +0800

    drm/amd/powerplay: fix variable type errors in smu_v11_0_setup_pptable
    
    fix size type errors, from uint32_t to uint16_t.
    it will cause only initializes the highest 16 bits in
    smu_get_atom_data_table function.
    
    bug report:
    This fixes the following static checker warning.
            drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:390 smu_v11_0_setup_pptable()
            warn: passing casted pointer '&size' to 'smu_get_atom_data_table()' 32 vs 16.
    
    Signed-off-by: Kevin Wang <kevin1.wang@amd.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 98f58ada2d37e68125c056f1fc005748251879c2
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Aug 15 08:27:09 2019 -0500

    drm/amdgpu/gfx9: update pg_flags after determining if gfx off is possible
    
    We need to set certain power gating flags after we determine
    if the firmware version is sufficient to support gfxoff.
    Previously we set the pg flags in early init, but we later
    we might have disabled gfxoff if the firmware versions didn't
    support it.  Move adding the additional pg flags after we
    determine whether or not to support gfxoff.
    
    Fixes: 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series (v2)")
    Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Tested-by: Tom St Denis <tom.stdenis@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: stable@vger.kernel.org

commit e4427372398c31f57450565de277f861a4db5b3b
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Mon Jun 10 19:22:55 2019 +0200

    selftests/kvm: make platform_info_test pass on AMD
    
    test_msr_platform_info_disabled() generates EXIT_SHUTDOWN but VMCB state
    is undefined after that so an attempt to launch this guest again from
    test_msr_platform_info_enabled() fails. Reorder the tests to make test
    pass.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit dc1a3e8e0cc6b2293b48c044710e63395aeb4fb4
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 19:18:34 2019 -0500

    dm raid: add missing cleanup in raid_ctr()
    
    If rs_prepare_reshape() fails, no cleanup is executed, leading to
    leak of the raid_set structure allocated at the beginning of
    raid_ctr(). To fix this issue, go to the label 'bad' if the error
    occurs.
    
    Fixes: 11e4723206683 ("dm raid: stop keeping raid set frozen altogether")
    Cc: stable@vger.kernel.org
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit e0702d90b79d430b0ccc276ead4f88440bb51352
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Aug 19 12:58:14 2019 +0300

    dm zoned: fix potential NULL dereference in dmz_do_reclaim()
    
    This function is supposed to return error pointers so it matches the
    dmz_get_rnd_zone_for_reclaim() function.  The current code could lead to
    a NULL dereference in dmz_do_reclaim()
    
    Fixes: b234c6d7a703 ("dm zoned: improve error handling in reclaim")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Dmitry Fomichev <dmitry.fomichev@wdc.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 08c04c84a5cde3af9baac0645a7496d6dcd76822
Author: Bryan Gurney <bgurney@redhat.com>
Date:   Fri Aug 16 10:09:53 2019 -0400

    dm dust: use dust block size for badblocklist index
    
    Change the "frontend" dust_remove_block, dust_add_block, and
    dust_query_block functions to store the "dust block number", instead
    of the sector number corresponding to the "dust block number".
    
    For the "backend" functions dust_map_read and dust_map_write,
    right-shift by sect_per_block_shift.  This fixes the inability to
    emulate failure beyond the first sector of each "dust block" (for
    devices with a "dust block size" larger than 512 bytes).
    
    Fixes: e4f3fabd67480bf ("dm: add dust target")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan Gurney <bgurney@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit ed19e3035c5a16034e896eed28c5e72e02e2ff58
Author: Imre Deak <imre.deak@intel.com>
Date:   Thu Aug 8 19:25:47 2019 +0300

    drm/i915: Fix HW readout for crtc_clock in HDMI mode
    
    The conversion during HDMI HW readout from port_clock to crtc_clock was
    missed when HDMI 10bpc support was added, so fix that.
    
    v2:
    - Unscrew the non-HDMI case.
    
    Fixes: cd9e11a8bf25 ("drm/i915/icl: Add 10-bit support for hdmi")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109593
    Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190808162547.7009-1-imre.deak@intel.com
    (cherry picked from commit 2969a78aead38b49e80c821a5c683544ab16160d)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit 3b5be16c7e90a69c93349d210766250fffcb54bd
Author: He Zhe <zhe.he@windriver.com>
Date:   Tue Aug 20 22:53:10 2019 +0800

    modules: page-align module section allocations only for arches supporting strict module rwx
    
    We should keep the case of "#define debug_align(X) (X)" for all arches
    without CONFIG_HAS_STRICT_MODULE_RWX ability, which would save people, who
    are sensitive to system size, a lot of memory when using modules,
    especially for embedded systems. This is also the intention of the
    original #ifdef... statement and still valid for now.
    
    Note that this still keeps the effect of the fix of the following commit,
    38f054d549a8 ("modules: always page-align module section allocations"),
    since when CONFIG_ARCH_HAS_STRICT_MODULE_RWX is enabled, module pages are
    aligned.
    
    Signed-off-by: He Zhe <zhe.he@windriver.com>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>

commit d012a06ab1d23178fc6856d8d2161fbcc4dd8ebd
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Aug 15 09:43:32 2019 +0200

    Revert "KVM: x86/mmu: Zap only the relevant pages when removing a memslot"
    
    This reverts commit 4e103134b862314dc2f2f18f2fb0ab972adc3f5f.
    Alex Williamson reported regressions with device assignment with
    this patch.  Even though the bug is probably elsewhere and still
    latent, this is needed to fix the regression.
    
    Fixes: 4e103134b862 ("KVM: x86/mmu: Zap only the relevant pages when removing a memslot", 2019-02-05)
    Reported-by: Alex Willamson <alex.williamson@redhat.com>
    Cc: stable@vger.kernel.org
    Cc: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 54577e5018a8c0cb79c9a0fa118a55c68715d398
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Aug 20 17:35:52 2019 +0200

    selftests: kvm: fix state save/load on processors without XSAVE
    
    state_test and smm_test are failing on older processors that do not
    have xcr0.  This is because on those processor KVM does provide
    support for KVM_GET/SET_XSAVE (to avoid having to rely on the older
    KVM_GET/SET_FPU) but not for KVM_GET/SET_XCRS.
    
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit c3cb6674df4c4a70f949e412dfe2230483092523
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Aug 20 19:07:46 2019 -0500

    video: fbdev: acornfb: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warning (Building: rpc_defconfig arm):
    
    drivers/video/fbdev/acornfb.c: In function ‘acornfb_parse_dram’:
    drivers/video/fbdev/acornfb.c:860:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
        size *= 1024;
        ~~~~~^~~~~~~
    drivers/video/fbdev/acornfb.c:861:3: note: here
       case 'K':
       ^~~~
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit da1fb2909e701ffbae8c5d6111f475603355e6e2
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Aug 20 16:20:05 2019 -0500

    scsi: libsas: sas_discover: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warning (Building: mtx1_defconfig mips):
    
    drivers/scsi/libsas/sas_discover.c: In function ‘sas_discover_domain’:
    ./include/linux/printk.h:309:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
      printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__)
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/scsi/libsas/sas_discover.c:459:3: note: in expansion of macro ‘pr_notice’
       pr_notice("ATA device seen but CONFIG_SCSI_SAS_ATA=N so cannot attach\n");
       ^~~~~~~~~
    drivers/scsi/libsas/sas_discover.c:462:2: note: here
      default:
      ^~~~~~~
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit 93cbcf5d22bbe6f2ecf64765d5f6085beceb3ee8
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Aug 20 16:03:09 2019 -0500

    MIPS: Octeon: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warning (Building: cavium_octeon_defconfig mips):
    
    arch/mips/include/asm/octeon/cvmx-sli-defs.h:47:6: warning: this statement
    may fall through [-Wimplicit-fallthrough=]
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit 5274fdba8e3c04e9ac1ba457379afc8835f9aa0f
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Aug 20 15:55:26 2019 -0500

    power: supply: ab8500_charger: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warning (Building: allmodconfig arm):
    
    drivers/power/supply/ab8500_charger.c: In function ‘ab8500_charger_max_usb_curr’:
    drivers/power/supply/ab8500_charger.c:738:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
       if (di->vbus_detected) {
          ^
    drivers/power/supply/ab8500_charger.c:745:2: note: here
      case USB_STAT_HM_IDGND:
      ^~~~
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit c9cbbb9f04f3ee27970f08d3aa6e6742a43d4ca5
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Aug 20 13:07:46 2019 -0500

    watchdog: wdt285: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warning (Building: footbridge_defconfig arm):
    
    drivers/watchdog/wdt285.c: In function ‘watchdog_ioctl’:
    drivers/watchdog/wdt285.c:170:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
       watchdog_ping();
       ^~~~~~~~~~~~~~~
    drivers/watchdog/wdt285.c:172:2: note: here
      case WDIOC_GETTIMEOUT:
      ^~~~
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit 3f0289cb9e0ee38e0075328e59b9cd88bf5ea474
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Aug 20 12:54:32 2019 -0500

    mtd: sa1100: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warning (Building: assabet_defconfig arm):
    
    drivers/mtd/maps/sa1100-flash.c: In function ‘sa1100_probe_subdev’:
    drivers/mtd/maps/sa1100-flash.c:82:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
       printk(KERN_WARNING "SA1100 flash: unknown base address "
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              "0x%08lx, assuming CS0\n", phys);
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/mtd/maps/sa1100-flash.c:85:2: note: here
      case SA1100_CS0_PHYS:
      ^~~~
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit 5334653d4ff29f5e1f216a2f5d3a86c19a479b1a
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Aug 20 12:47:06 2019 -0500

    drm/sun4i: tcon: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warning (Building: sunxi_defconfig arm):
    
    drivers/gpu/drm/sun4i/sun4i_tcon.c: In function ‘sun4i_tcon0_mode_set_dithering’:
    drivers/gpu/drm/sun4i/sun4i_tcon.c:318:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
       val |= SUN4I_TCON0_FRM_CTL_MODE_B;
    drivers/gpu/drm/sun4i/sun4i_tcon.c:319:2: note: here
      case MEDIA_BUS_FMT_RGB666_1X18:
      ^~~~
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit edf6a05976980b5c21f19a60fde175f736e4ab61
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Aug 20 13:01:03 2019 -0500

    drm/sun4i: sun6i_mipi_dsi: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warning (Building: multi_v7_defconfig arm):
    
    drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function ‘sun6i_dsi_transfer’:
    drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:993:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
       if (msg->rx_len == 1) {
          ^
    drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:998:2: note: here
      default:
      ^~~~~~~
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit 06264adfa2bcc8abb556dec9af0e86150a67faf0
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Aug 20 19:29:16 2019 -0500

    ARM: riscpc: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warning (Building: rpc_defconfig arm):
    
    arch/arm/mach-rpc/riscpc.c: In function ‘parse_tag_acorn’:
    arch/arm/mach-rpc/riscpc.c:48:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
       vram_size += PAGE_SIZE * 256;
       ~~~~~~~~~~^~~~~~~~~~~~~~~~~~
    arch/arm/mach-rpc/riscpc.c:49:2: note: here
      case 256:
      ^~~~
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit 377ec83643efcae869528b4b26a5070fdeba3abd
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Sun Aug 11 19:18:03 2019 -0500

    dmaengine: fsldma: Mark expected switch fall-through
    
    Mark switch cases where we are expecting to fall through.
    
    Fix the following warnings (Building: powerpc-ppa8548_defconfig powerpc):
    
    drivers/dma/fsldma.c: In function ‘fsl_dma_chan_probe’:
    drivers/dma/fsldma.c:1165:26: warning: this statement may fall through [-Wimplicit-fallthrough=]
       chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
       ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/dma/fsldma.c:1166:2: note: here
      case FSL_DMA_IP_83XX:
      ^~~~
    
    Reported-by: kbuild test robot <lkp@intel.com>
    Acked-by: Li Yang <leoyang.li@nxp.com>
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit 2323d7baab2b18d87d9bc267452e387aa9f0060a
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 13:54:46 2019 -0500

    infiniband: hfi1: fix memory leaks
    
    In fault_opcodes_write(), 'data' is allocated through kcalloc(). However,
    it is not deallocated in the following execution if an error occurs,
    leading to memory leaks. To fix this issue, introduce the 'free_data' label
    to free 'data' before returning the error.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Acked-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Link: https://lore.kernel.org/r/1566154486-3713-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit b08afa064c320e5d85cdc27228426b696c4c8dae
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 14:29:31 2019 -0500

    infiniband: hfi1: fix a memory leak bug
    
    In fault_opcodes_read(), 'data' is not deallocated if debugfs_file_get()
    fails, leading to a memory leak. To fix this bug, introduce the 'free_data'
    label to free 'data' before returning the error.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Acked-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Link: https://lore.kernel.org/r/1566156571-4335-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 5c1baaa82cea2c815a5180ded402a7cd455d1810
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 15:23:01 2019 -0500

    IB/mlx4: Fix memory leaks
    
    In mlx4_ib_alloc_pv_bufs(), 'tun_qp->tx_ring' is allocated through
    kcalloc(). However, it is not always deallocated in the following execution
    if an error occurs, leading to memory leaks. To fix this issue, free
    'tun_qp->tx_ring' whenever an error occurs.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Acked-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/1566159781-4642-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit a7bfb93f0211b4a2f1ffeeb259ed6206bac30460
Author: zhengbin <zhengbin13@huawei.com>
Date:   Mon Aug 19 12:27:39 2019 +0800

    RDMA/cma: fix null-ptr-deref Read in cma_cleanup
    
    In cma_init, if cma_configfs_init fails, need to free the
    previously memory and return fail, otherwise will trigger
    null-ptr-deref Read in cma_cleanup.
    
    cma_cleanup
      cma_configfs_exit
        configfs_unregister_subsystem
    
    Fixes: 045959db65c6 ("IB/cma: Add configfs for rdma_cm")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: zhengbin <zhengbin13@huawei.com>
    Reviewed-by: Parav Pandit <parav@mellanox.com>
    Link: https://lore.kernel.org/r/1566188859-103051-1-git-send-email-zhengbin13@huawei.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 841b07f99a4766d66f50d8a2ab941bce94cd4e70
Author: Moni Shoua <monis@mellanox.com>
Date:   Thu Aug 15 11:38:34 2019 +0300

    IB/mlx5: Block MR WR if UMR is not possible
    
    Check conditions that are mandatory to post_send UMR WQEs.
    1. Modifying page size.
    2. Modifying remote atomic permissions if atomic access is required.
    
    If either condition is not fulfilled then fail to post_send() flow.
    
    Fixes: c8d75a980fab ("IB/mlx5: Respect new UMR capabilities")
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Reviewed-by: Guy Levi <guyle@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20190815083834.9245-9-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 25a4517214ffa217a443181f7f885b914e6b328f
Author: Moni Shoua <monis@mellanox.com>
Date:   Thu Aug 15 11:38:33 2019 +0300

    IB/mlx5: Fix MR re-registration flow to use UMR properly
    
    The UMR WQE in the MR re-registration flow requires that
    modify_atomic and modify_entity_size capabilities are enabled.
    Therefore, check that the these capabilities are present before going to
    umr flow and go through slow path if not.
    
    Fixes: c8d75a980fab ("IB/mlx5: Respect new UMR capabilities")
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Reviewed-by: Guy Levi <guyle@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20190815083834.9245-8-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 008157528ac5658502c0f87e872778c56c41109c
Author: Moni Shoua <monis@mellanox.com>
Date:   Thu Aug 15 11:38:32 2019 +0300

    IB/mlx5: Report and handle ODP support properly
    
    ODP depends on the several device capabilities, among them is the ability
    to send UMR WQEs with that modify atomic and entity size of the MR.
    Therefore, only if all conditions to send such a UMR WQE are met then
    driver can report that ODP is supported. Use this check of conditions
    in all places where driver needs to know about ODP support.
    
    Also, implicit ODP support depends on ability of driver to send UMR WQEs
    for an indirect mkey. Therefore, verify that all conditions to do so are
    met when reporting support.
    
    Fixes: c8d75a980fab ("IB/mlx5: Respect new UMR capabilities")
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Reviewed-by: Guy Levi <guyle@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20190815083834.9245-7-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 0e6613b41edd2f55a4b33234c5f31410c1ed3783
Author: Moni Shoua <monis@mellanox.com>
Date:   Thu Aug 15 11:38:31 2019 +0300

    IB/mlx5: Consolidate use_umr checks into single function
    
    Introduce helper function to unify various use_umr checks.
    
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20190815083834.9245-6-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 60c78668ae50d6b815ead4a62216822a92097125
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Thu Aug 15 11:38:29 2019 +0300

    RDMA/restrack: Rewrite PID namespace check to be reliable
    
    task_active_pid_ns() is wrong API to check PID namespace because it
    posses some restrictions and return PID namespace where the process
    was allocated. It created mismatches with current namespace, which
    can be different.
    
    Rewrite whole rdma_is_visible_in_pid_ns() logic to provide reliable
    results without any relation to allocated PID namespace.
    
    Fixes: 8be565e65fa9 ("RDMA/nldev: Factor out the PID namespace check")
    Fixes: 6a6c306a09b5 ("RDMA/restrack: Make is_visible_in_pid_ns() as an API")
    Reviewed-by: Mark Zhang <markz@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20190815083834.9245-4-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit c8b32408b4074232d93e64b6c23b2aa96dde448e
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Thu Aug 15 11:38:28 2019 +0300

    RDMA/counters: Properly implement PID checks
    
    "Auto" configuration mode is called for visible in that PID
    namespace and it ensures that all counters and QPs are coexist
    in the same namespace and belong to same PID.
    
    Fixes: 99fa331dc862 ("RDMA/counter: Add "auto" configuration mode support")
    Reviewed-by: Mark Zhang <markz@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20190815083834.9245-3-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 948a7287b29e06b8c629f5e70235d857a175ceaf
Author: Ido Kalir <idok@mellanox.com>
Date:   Thu Aug 15 11:38:27 2019 +0300

    IB/core: Fix NULL pointer dereference when bind QP to counter
    
    If QP is not visible to the pid, then we try to decrease its reference
    count and return from the function before the QP pointer is
    initialized. This lead to NULL pointer dereference.
    Fix it by pass directly the res to the rdma_restract_put as arg instead of
    &qp->res.
    
    This fixes below call trace:
    [ 5845.110329] BUG: kernel NULL pointer dereference, address:
    00000000000000dc
    [ 5845.120482] Oops: 0002 [#1] SMP PTI
    [ 5845.129119] RIP: 0010:rdma_restrack_put+0x5/0x30 [ib_core]
    [ 5845.169450] Call Trace:
    [ 5845.170544]  rdma_counter_get_qp+0x5c/0x70 [ib_core]
    [ 5845.172074]  rdma_counter_bind_qpn_alloc+0x6f/0x1a0 [ib_core]
    [ 5845.173731]  nldev_stat_set_doit+0x314/0x330 [ib_core]
    [ 5845.175279]  rdma_nl_rcv_msg+0xeb/0x1d0 [ib_core]
    [ 5845.176772]  ? __kmalloc_node_track_caller+0x20b/0x2b0
    [ 5845.178321]  rdma_nl_rcv+0xcb/0x120 [ib_core]
    [ 5845.179753]  netlink_unicast+0x179/0x220
    [ 5845.181066]  netlink_sendmsg+0x2d8/0x3d0
    [ 5845.182338]  sock_sendmsg+0x30/0x40
    [ 5845.183544]  __sys_sendto+0xdc/0x160
    [ 5845.184832]  ? syscall_trace_enter+0x1f8/0x2e0
    [ 5845.186209]  ? __audit_syscall_exit+0x1d9/0x280
    [ 5845.187584]  __x64_sys_sendto+0x24/0x30
    [ 5845.188867]  do_syscall_64+0x48/0x120
    [ 5845.190097]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 1bd8e0a9d0fd1 ("RDMA/counter: Allow manual mode configuration support")
    Signed-off-by: Ido Kalir <idok@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20190815083834.9245-2-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit d9d1f5e7bb82415591e8b62b222cbb88c4797ef3
Author: Kaike Wan <kaike.wan@intel.com>
Date:   Thu Aug 15 15:20:58 2019 -0400

    IB/hfi1: Drop stale TID RDMA packets that cause TIDErr
    
    In a congested fabric with adaptive routing enabled, traces show that
    packets could be delivered out of order. A stale TID RDMA data packet
    could lead to TidErr if the TID entries have been released by duplicate
    data packets generated from retries, and subsequently erroneously force
    the qp into error state in the current implementation.
    
    Since the payload has already been dropped by hardware, the packet can
    be simply dropped and it is no longer necessary to put the qp into
    error state.
    
    Fixes: 9905bf06e890 ("IB/hfi1: Add functions to receive TID RDMA READ response")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Link: https://lore.kernel.org/r/20190815192058.105923.72324.stgit@awfm-01.aw.intel.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 90fdae66e72bf0381d168f12dca0259617927895
Author: Kaike Wan <kaike.wan@intel.com>
Date:   Thu Aug 15 15:20:51 2019 -0400

    IB/hfi1: Add additional checks when handling TID RDMA WRITE DATA packet
    
    In a congested fabric with adaptive routing enabled, traces show that
    packets could be delivered out of order, which could cause incorrect
    processing of stale packets. For stale TID RDMA WRITE DATA packets that
    cause KDETH EFLAGS errors, this patch adds additional checks before
    processing the packets.
    
    Fixes: d72fe7d5008b ("IB/hfi1: Add a function to receive TID RDMA WRITE DATA packet")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Link: https://lore.kernel.org/r/20190815192051.105923.69979.stgit@awfm-01.aw.intel.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit a8adbf7d0d0a6e3bf7f99da461a06039364e028b
Author: Kaike Wan <kaike.wan@intel.com>
Date:   Thu Aug 15 15:20:45 2019 -0400

    IB/hfi1: Add additional checks when handling TID RDMA READ RESP packet
    
    In a congested fabric with adaptive routing enabled, traces show that
    packets could be delivered out of order, which could cause incorrect
    processing of stale packets. For stale TID RDMA READ RESP packets that
    cause KDETH EFLAGS errors, this patch adds additional checks before
    processing the packets.
    
    Fixes: 9905bf06e890 ("IB/hfi1: Add functions to receive TID RDMA READ response")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Link: https://lore.kernel.org/r/20190815192045.105923.59813.stgit@awfm-01.aw.intel.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 35d5c8b82e2c32e8e29ca195bb4dac60ba7d97fc
Author: Kaike Wan <kaike.wan@intel.com>
Date:   Thu Aug 15 15:20:39 2019 -0400

    IB/hfi1: Unsafe PSN checking for TID RDMA READ Resp packet
    
    When processing a TID RDMA READ RESP packet that causes KDETH EFLAGS
    errors, the packet's IB PSN is checked against qp->s_last_psn and
    qp->s_psn without the protection of qp->s_lock, which is not safe.
    
    This patch fixes the issue by acquiring qp->s_lock first.
    
    Fixes: 9905bf06e890 ("IB/hfi1: Add functions to receive TID RDMA READ response")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Link: https://lore.kernel.org/r/20190815192039.105923.7852.stgit@awfm-01.aw.intel.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit d58c1834bf0d218a0bc00f8fb44874551b21da84
Author: Kaike Wan <kaike.wan@intel.com>
Date:   Thu Aug 15 15:20:33 2019 -0400

    IB/hfi1: Drop stale TID RDMA packets
    
    In a congested fabric with adaptive routing enabled, traces show that
    the sender could receive stale TID RDMA NAK packets that contain newer
    KDETH PSNs and older Verbs PSNs. If not dropped, these packets could
    cause the incorrect rewinding of the software flows and the incorrect
    completion of TID RDMA WRITE requests, and eventually leading to memory
    corruption and kernel crash.
    
    The current code drops stale TID RDMA ACK/NAK packets solely based
    on KDETH PSNs, which may lead to erroneous processing. This patch
    fixes the issue by also checking the Verbs PSN. Addition checks are
    added before rewinding the TID RDMA WRITE DATA packets.
    
    Fixes: 9e93e967f7b4 ("IB/hfi1: Add a function to receive TID RDMA ACK packet")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Link: https://lore.kernel.org/r/20190815192033.105923.44192.stgit@awfm-01.aw.intel.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>

commit 9b440078017f194e56eaae3ac3…
metux added a commit to metux/linux that referenced this pull request Nov 21, 2019
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
chewitt pushed a commit to chewitt/linux that referenced this pull request Dec 2, 2019
[ Upstream commit af8a85a ]

Calling ceph_buffer_put() in fill_inode() may result in freeing the
i_xattrs.blob buffer while holding the i_ceph_lock.  This can be fixed by
postponing the call until later, when the lock is released.

The following backtrace was triggered by fstests generic/070.

  BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
  in_atomic(): 1, irqs_disabled(): 0, pid: 3852, name: kworker/0:4
  6 locks held by kworker/0:4/3852:
   #0: 000000004270f6bb ((wq_completion)ceph-msgr){+.+.}, at: process_one_work+0x1b8/0x5f0
   #1: 00000000eb420803 ((work_completion)(&(&con->work)->work)){+.+.}, at: process_one_work+0x1b8/0x5f0
   #2: 00000000be1c53a4 (&s->s_mutex){+.+.}, at: dispatch+0x288/0x1476
   #3: 00000000559cb958 (&mdsc->snap_rwsem){++++}, at: dispatch+0x2eb/0x1476
   #4: 000000000d5ebbae (&req->r_fill_mutex){+.+.}, at: dispatch+0x2fc/0x1476
   #5: 00000000a83d0514 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: fill_inode.isra.0+0xf8/0xf70
  CPU: 0 PID: 3852 Comm: kworker/0:4 Not tainted 5.2.0+ torvalds#441
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
  Workqueue: ceph-msgr ceph_con_workfn
  Call Trace:
   dump_stack+0x67/0x90
   ___might_sleep.cold+0x9f/0xb1
   vfree+0x4b/0x60
   ceph_buffer_release+0x1b/0x60
   fill_inode.isra.0+0xa9b/0xf70
   ceph_fill_trace+0x13b/0xc70
   ? dispatch+0x2eb/0x1476
   dispatch+0x320/0x1476
   ? __mutex_unlock_slowpath+0x4d/0x2a0
   ceph_con_workfn+0xc97/0x2ec0
   ? process_one_work+0x1b8/0x5f0
   process_one_work+0x244/0x5f0
   worker_thread+0x4d/0x3e0
   kthread+0x105/0x140
   ? process_one_work+0x5f0/0x5f0
   ? kthread_park+0x90/0x90
   ret_from_fork+0x3a/0x50

Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
metux added a commit to metux/linux that referenced this pull request Jan 10, 2020
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
RebelLion420 pushed a commit to RebelLion420/kernel_perry that referenced this pull request Mar 4, 2020
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cyclon1978 pushed a commit to cyclon1978/android_kernel_honor_berlin that referenced this pull request Mar 16, 2020
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rudcode pushed a commit to rudcode/android_kernel_sony_msm8996 that referenced this pull request Mar 29, 2020
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
axonasif pushed a commit to axonasif/linux-kernel that referenced this pull request May 24, 2020
commit 8e75f7a upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
goldfish07 pushed a commit to goldfish07/android_kernel_moto_panelli that referenced this pull request Jun 12, 2020
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
samueldr pushed a commit to samueldr/linux that referenced this pull request Jun 28, 2020
commit 8e75f7a upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bphaslett pushed a commit to bphaslett/android_kernel_amazon_karnak that referenced this pull request Jul 8, 2020
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
adeii pushed a commit to adeii/huawei-london-kernel that referenced this pull request Jul 26, 2020
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
goldfish07 pushed a commit to goldfish07/android_kernel_samsung_j8y18lte-8.0 that referenced this pull request Jul 31, 2020
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huawei-Dev pushed a commit to Huawei-Dev/android_kernel_huawei_btv that referenced this pull request Nov 1, 2020
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
metux added a commit to metux/linux that referenced this pull request Feb 4, 2021
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Feb 7, 2021
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Feb 7, 2021
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Feb 8, 2021
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request May 22, 2021
the following script:

  # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2
  # tc qdisc add dev eth0 clsact
  # tc filter add dev eth0 egress matchall action skbedit priority 0x10002
  # ping 192.0.2.2 -I eth0 -c2 -w1 -q

produces the following splat:

 BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
 Read of size 4 at addr ffff888171306924 by task ping/942

 CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ torvalds#441
 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
 Call Trace:
  dump_stack+0x92/0xc1
  print_address_description.constprop.7+0x1a/0x150
  kasan_report.cold.13+0x7f/0x111
  fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
  __dev_queue_xmit+0x1034/0x2b10
  ip_finish_output2+0xc62/0x2120
  __ip_finish_output+0x553/0xea0
  ip_output+0x1ca/0x4d0
  ip_send_skb+0x37/0xa0
  raw_sendmsg+0x1c4b/0x2d00
  sock_sendmsg+0xdb/0x110
  __sys_sendto+0x1d7/0x2b0
  __x64_sys_sendto+0xdd/0x1b0
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7fe69735c3eb
 Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89
 RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
 RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb
 RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003
 RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010
 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260
 R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0

 Allocated by task 917:
  kasan_save_stack+0x19/0x40
  __kasan_kmalloc+0x7f/0xa0
  __kmalloc_node+0x139/0x280
  fq_pie_init+0x555/0x8e8 [sch_fq_pie]
  qdisc_create+0x407/0x11b0
  tc_modify_qdisc+0x3c2/0x17e0
  rtnetlink_rcv_msg+0x346/0x8e0
  netlink_rcv_skb+0x120/0x380
  netlink_unicast+0x439/0x630
  netlink_sendmsg+0x719/0xbf0
  sock_sendmsg+0xe2/0x110
  ____sys_sendmsg+0x5ba/0x890
  ___sys_sendmsg+0xe9/0x160
  __sys_sendmsg+0xd3/0x170
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 The buggy address belongs to the object at ffff888171306800
  which belongs to the cache kmalloc-256 of size 256
 The buggy address is located 36 bytes to the right of
  256-byte region [ffff888171306800, ffff888171306900)
 The buggy address belongs to the page:
 page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306
 head:00000000bcfb624e order:1 compound_mapcount:0
 flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
 raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40
 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
 >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                ^
  ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a
valid flow: it's an address beyond the allocated memory.

Fixes: ec97ecf ("net: sched: add Flow Queue PIE packet scheduler")
CC: stable@vger.kernel.org
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request May 24, 2021
the following script:

  # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2
  # tc qdisc add dev eth0 clsact
  # tc filter add dev eth0 egress matchall action skbedit priority 0x10002
  # ping 192.0.2.2 -I eth0 -c2 -w1 -q

produces the following splat:

 BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
 Read of size 4 at addr ffff888171306924 by task ping/942

 CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ torvalds#441
 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
 Call Trace:
  dump_stack+0x92/0xc1
  print_address_description.constprop.7+0x1a/0x150
  kasan_report.cold.13+0x7f/0x111
  fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
  __dev_queue_xmit+0x1034/0x2b10
  ip_finish_output2+0xc62/0x2120
  __ip_finish_output+0x553/0xea0
  ip_output+0x1ca/0x4d0
  ip_send_skb+0x37/0xa0
  raw_sendmsg+0x1c4b/0x2d00
  sock_sendmsg+0xdb/0x110
  __sys_sendto+0x1d7/0x2b0
  __x64_sys_sendto+0xdd/0x1b0
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7fe69735c3eb
 Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89
 RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
 RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb
 RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003
 RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010
 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260
 R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0

 Allocated by task 917:
  kasan_save_stack+0x19/0x40
  __kasan_kmalloc+0x7f/0xa0
  __kmalloc_node+0x139/0x280
  fq_pie_init+0x555/0x8e8 [sch_fq_pie]
  qdisc_create+0x407/0x11b0
  tc_modify_qdisc+0x3c2/0x17e0
  rtnetlink_rcv_msg+0x346/0x8e0
  netlink_rcv_skb+0x120/0x380
  netlink_unicast+0x439/0x630
  netlink_sendmsg+0x719/0xbf0
  sock_sendmsg+0xe2/0x110
  ____sys_sendmsg+0x5ba/0x890
  ___sys_sendmsg+0xe9/0x160
  __sys_sendmsg+0xd3/0x170
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 The buggy address belongs to the object at ffff888171306800
  which belongs to the cache kmalloc-256 of size 256
 The buggy address is located 36 bytes to the right of
  256-byte region [ffff888171306800, ffff888171306900)
 The buggy address belongs to the page:
 page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306
 head:00000000bcfb624e order:1 compound_mapcount:0
 flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
 raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40
 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
 >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                ^
  ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a
valid flow: it's an address beyond the allocated memory.

Fixes: ec97ecf ("net: sched: add Flow Queue PIE packet scheduler")
CC: stable@vger.kernel.org
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Igortorrente pushed a commit to Igortorrente/linux that referenced this pull request May 31, 2021
the following script:

  # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2
  # tc qdisc add dev eth0 clsact
  # tc filter add dev eth0 egress matchall action skbedit priority 0x10002
  # ping 192.0.2.2 -I eth0 -c2 -w1 -q

produces the following splat:

 BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
 Read of size 4 at addr ffff888171306924 by task ping/942

 CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ torvalds#441
 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
 Call Trace:
  dump_stack+0x92/0xc1
  print_address_description.constprop.7+0x1a/0x150
  kasan_report.cold.13+0x7f/0x111
  fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
  __dev_queue_xmit+0x1034/0x2b10
  ip_finish_output2+0xc62/0x2120
  __ip_finish_output+0x553/0xea0
  ip_output+0x1ca/0x4d0
  ip_send_skb+0x37/0xa0
  raw_sendmsg+0x1c4b/0x2d00
  sock_sendmsg+0xdb/0x110
  __sys_sendto+0x1d7/0x2b0
  __x64_sys_sendto+0xdd/0x1b0
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7fe69735c3eb
 Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89
 RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
 RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb
 RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003
 RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010
 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260
 R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0

 Allocated by task 917:
  kasan_save_stack+0x19/0x40
  __kasan_kmalloc+0x7f/0xa0
  __kmalloc_node+0x139/0x280
  fq_pie_init+0x555/0x8e8 [sch_fq_pie]
  qdisc_create+0x407/0x11b0
  tc_modify_qdisc+0x3c2/0x17e0
  rtnetlink_rcv_msg+0x346/0x8e0
  netlink_rcv_skb+0x120/0x380
  netlink_unicast+0x439/0x630
  netlink_sendmsg+0x719/0xbf0
  sock_sendmsg+0xe2/0x110
  ____sys_sendmsg+0x5ba/0x890
  ___sys_sendmsg+0xe9/0x160
  __sys_sendmsg+0xd3/0x170
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 The buggy address belongs to the object at ffff888171306800
  which belongs to the cache kmalloc-256 of size 256
 The buggy address is located 36 bytes to the right of
  256-byte region [ffff888171306800, ffff888171306900)
 The buggy address belongs to the page:
 page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306
 head:00000000bcfb624e order:1 compound_mapcount:0
 flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
 raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40
 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
 >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                ^
  ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a
valid flow: it's an address beyond the allocated memory.

Fixes: ec97ecf ("net: sched: add Flow Queue PIE packet scheduler")
CC: stable@vger.kernel.org
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
intersectRaven pushed a commit to intersectRaven/linux that referenced this pull request Jun 3, 2021
commit e70f7a1 upstream.

the following script:

  # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2
  # tc qdisc add dev eth0 clsact
  # tc filter add dev eth0 egress matchall action skbedit priority 0x10002
  # ping 192.0.2.2 -I eth0 -c2 -w1 -q

produces the following splat:

 BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
 Read of size 4 at addr ffff888171306924 by task ping/942

 CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ torvalds#441
 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
 Call Trace:
  dump_stack+0x92/0xc1
  print_address_description.constprop.7+0x1a/0x150
  kasan_report.cold.13+0x7f/0x111
  fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
  __dev_queue_xmit+0x1034/0x2b10
  ip_finish_output2+0xc62/0x2120
  __ip_finish_output+0x553/0xea0
  ip_output+0x1ca/0x4d0
  ip_send_skb+0x37/0xa0
  raw_sendmsg+0x1c4b/0x2d00
  sock_sendmsg+0xdb/0x110
  __sys_sendto+0x1d7/0x2b0
  __x64_sys_sendto+0xdd/0x1b0
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7fe69735c3eb
 Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89
 RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
 RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb
 RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003
 RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010
 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260
 R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0

 Allocated by task 917:
  kasan_save_stack+0x19/0x40
  __kasan_kmalloc+0x7f/0xa0
  __kmalloc_node+0x139/0x280
  fq_pie_init+0x555/0x8e8 [sch_fq_pie]
  qdisc_create+0x407/0x11b0
  tc_modify_qdisc+0x3c2/0x17e0
  rtnetlink_rcv_msg+0x346/0x8e0
  netlink_rcv_skb+0x120/0x380
  netlink_unicast+0x439/0x630
  netlink_sendmsg+0x719/0xbf0
  sock_sendmsg+0xe2/0x110
  ____sys_sendmsg+0x5ba/0x890
  ___sys_sendmsg+0xe9/0x160
  __sys_sendmsg+0xd3/0x170
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 The buggy address belongs to the object at ffff888171306800
  which belongs to the cache kmalloc-256 of size 256
 The buggy address is located 36 bytes to the right of
  256-byte region [ffff888171306800, ffff888171306900)
 The buggy address belongs to the page:
 page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306
 head:00000000bcfb624e order:1 compound_mapcount:0
 flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
 raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40
 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
 >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                ^
  ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a
valid flow: it's an address beyond the allocated memory.

Fixes: ec97ecf ("net: sched: add Flow Queue PIE packet scheduler")
CC: stable@vger.kernel.org
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mansr pushed a commit to victronenergy/linux that referenced this pull request Jun 3, 2021
commit e70f7a1 upstream.

the following script:

  # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2
  # tc qdisc add dev eth0 clsact
  # tc filter add dev eth0 egress matchall action skbedit priority 0x10002
  # ping 192.0.2.2 -I eth0 -c2 -w1 -q

produces the following splat:

 BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
 Read of size 4 at addr ffff888171306924 by task ping/942

 CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ torvalds#441
 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
 Call Trace:
  dump_stack+0x92/0xc1
  print_address_description.constprop.7+0x1a/0x150
  kasan_report.cold.13+0x7f/0x111
  fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
  __dev_queue_xmit+0x1034/0x2b10
  ip_finish_output2+0xc62/0x2120
  __ip_finish_output+0x553/0xea0
  ip_output+0x1ca/0x4d0
  ip_send_skb+0x37/0xa0
  raw_sendmsg+0x1c4b/0x2d00
  sock_sendmsg+0xdb/0x110
  __sys_sendto+0x1d7/0x2b0
  __x64_sys_sendto+0xdd/0x1b0
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7fe69735c3eb
 Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89
 RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
 RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb
 RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003
 RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010
 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260
 R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0

 Allocated by task 917:
  kasan_save_stack+0x19/0x40
  __kasan_kmalloc+0x7f/0xa0
  __kmalloc_node+0x139/0x280
  fq_pie_init+0x555/0x8e8 [sch_fq_pie]
  qdisc_create+0x407/0x11b0
  tc_modify_qdisc+0x3c2/0x17e0
  rtnetlink_rcv_msg+0x346/0x8e0
  netlink_rcv_skb+0x120/0x380
  netlink_unicast+0x439/0x630
  netlink_sendmsg+0x719/0xbf0
  sock_sendmsg+0xe2/0x110
  ____sys_sendmsg+0x5ba/0x890
  ___sys_sendmsg+0xe9/0x160
  __sys_sendmsg+0xd3/0x170
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 The buggy address belongs to the object at ffff888171306800
  which belongs to the cache kmalloc-256 of size 256
 The buggy address is located 36 bytes to the right of
  256-byte region [ffff888171306800, ffff888171306900)
 The buggy address belongs to the page:
 page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306
 head:00000000bcfb624e order:1 compound_mapcount:0
 flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
 raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40
 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
 >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                ^
  ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a
valid flow: it's an address beyond the allocated memory.

Fixes: ec97ecf ("net: sched: add Flow Queue PIE packet scheduler")
CC: stable@vger.kernel.org
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sodar pushed a commit to sodar/linux that referenced this pull request Jul 13, 2021
rust: Removes alloc_error_handler feature
turex pushed a commit to turex/labyrinth_kernel_prague that referenced this pull request Dec 1, 2021
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ggow pushed a commit to lineage16-suez/kernel_amazon_suez that referenced this pull request Apr 10, 2022
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit cf924d80ece3b3e549efdc96fc4ea5d219410692)
youheng7185 pushed a commit to youheng7185/j2y18lte-kernel-upstream that referenced this pull request Jun 3, 2023
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
FlorinelulX pushed a commit to FlorinelulX/android_kernel_huawei_hi6250-8 that referenced this pull request Feb 14, 2024
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: torvalds/linux#441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants