date:20210324

Re: [PATCH] scripts: stable: add script to validate backports

2021-03-24 Thread Greg Kroah-Hartman

On Tue, Mar 23, 2021 at 01:28:38PM -0700, Nick Desaulniers wrote:
> On Tue, Mar 23, 2021 at 12:05 PM Greg Kroah-Hartman
>  wrote:
> >
> > The only time git gets involved is when we do a -rc release or when we
> > do a "real" release, and then we use 'git quiltimport' on the whole
> > stack.
> >
> > Here's a script that I use (much too slow, I know), for checking this
> > type of thing and I try to remember to run it before every cycle of -rc
> > releases:
> > 
> > https://github.com/gregkh/commit_tree/blob/master/find_fixes_in_queue
> >
> > It's a hack, and picks up more things than is really needed, but I would
> > rather it error on that side than the other.
> 
> Yes, my script is similar.  Looks like yours also runs on a git tree.
> 
> I noticed that id_fixed_in runs `git grep -l --threads=3 ` to
> find fixes; that's neat, I didn't know about `--threads=`.  I tried it
> with ae46578b963f manually:
> 
> $ git grep -l --threads=3 ae46578b963f
> $
> 
> Should it have found a7889c6320b9 and 773e0c402534?  Perhaps `git log
> --grep=` should be used instead?  I thought `git grep` only greps
> files in the archive, not commit history?

Yes, it does only grep the files in the archive.

But look closer at the archive that this script lives in :)

This archive is a "blown up" copy of the Linux kernel tree, with one
file per commit.  The name of the file is the commit id, and the content
of the file is the changelog of the commit itself.

So it's a hack that I use to be able to simply search the changelogs of
all commits to find out if they have a "Fixes:" tag with a specific
commit id in it.

So in your example above, in the repo I run it and get:

~/linux/stable/commit_tree $ git grep -l --threads=3 ae46578b963f
changes/5.2/773e0c40253443e0ce5491cb0e414b62f7cc45ed
ids/5.2

Which shows me that in commit 773e0c402534 ("afs: Fix
afs_xattr_get_yfs() to not try freeing an error value") in the kernel
tree, it has a "Fixes:" tag that references "ae46578b963f".

It also shows me that commit ae46578b963f was contained in the 5.2
kernel release, as I use the "ids/" subdirectory here for other fast
lookups (it's a tiny bit faster than 'git describe --contains').

I don't know how your script is walking through all possible commits to
see if they are fixing a specific one, maybe I should look and see if
it's doing it better than my "git tree/directory as a database hack"
does :)

thanks,

greg k-h

Re: [PATCH v4 1/4] drm: sun4i: dsi: Use drm_of_find_panel_or_bridge

2021-03-24 Thread Laurent Pinchart

Hi Jagan,

On Wed, Mar 24, 2021 at 03:19:10PM +0530, Jagan Teki wrote:
> On Wed, Mar 24, 2021 at 3:09 PM Laurent Pinchart wrote:
> > On Wed, Mar 24, 2021 at 02:44:57PM +0530, Jagan Teki wrote:
> > > On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland wrote:
> > > > On 3/23/21 5:53 PM, Laurent Pinchart wrote:
> > > > > On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
> > > > >> Replace of_drm_find_panel with drm_of_find_panel_or_bridge
> > > > >> for finding panel, this indeed help to find the bridge if
> > > > >> bridge support added.
> > > > >>
> > > > >> Added NULL in bridge argument, same will replace with bridge
> > > > >> parameter once bridge supported.
> > > > >>
> > > > >> Signed-off-by: Jagan Teki 
> > > > >
> > > > > Looks good, there should be no functional change.
> > > >
> > > > Actually this breaks all existing users of this driver, see below.
> > > >
> > > > > Reviewed-by: Laurent Pinchart 
> > > > >
> > > > >> ---
> > > > >> Changes for v4, v3:
> > > > >> - none
> > > > >>
> > > > >>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 ---
> > > > >>  1 file changed, 8 insertions(+), 3 deletions(-)
> > > > >>
> > > > >> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > > >> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > >> index 4f5efcace68e..2e9e7b2d4145 100644
> > > > >> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > >> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > >> @@ -21,6 +21,7 @@
> > > > >>
> > > > >>  #include 
> > > > >>  #include 
> > > > >> +#include 
> > > > >>  #include 
> > > > >>  #include 
> > > > >>  #include 
> > > > >> @@ -963,10 +964,14 @@ static int sun6i_dsi_attach(struct 
> > > > >> mipi_dsi_host *host,
> > > > >>  struct mipi_dsi_device *device)
> > > > >>  {
> > > > >>  struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> > > > >> -struct drm_panel *panel = 
> > > > >> of_drm_find_panel(device->dev.of_node);
> > > >
> > > > This is using the OF node of the DSI device, which is a direct child of
> > > > the DSI host's OF node. There is no OF graph involved.
> > > >
> > > > >> +struct drm_panel *panel;
> > > > >> +int ret;
> > > > >> +
> > > > >> +ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
> > > > >> +  &panel, NULL);
> > > >
> > > > However, this function expects to find the panel using OF graph. This
> > > > does not work with existing device trees (PinePhone, PineTab) which do
> > > > not use OF graph to connect the panel. And it cannot work, because the
> > > > DSI host's binding specifies a single port: the input port from the
> > > > display engine.
> > >
> > > Thanks for noticing this. I did understand your point and yes, I did
> > > mention the updated pipeline in previous versions and forgot to add it
> > > to this series.
> > >
> > > Here is the updated pipeline to make it work:
> > >
> > > https://patchwork.kernel.org/project/dri-devel/patch/20190524104252.20236-1-ja...@amarulasolutions.com/
> > >
> > > Let me know your comments on this, so I will add a patch for the
> > > above-affected DTS files.
> >
> > DT is an ABI, we need to ensure backward compatibility. Changes in
> > kernel drivers can't break devices that have an old DT.
> 
> Thanks for your point.
> 
> So, we need to choose APIs that would compatible with the old DT and
> new DT changes. Am I correct?

Yes, that's correct.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v4 2/4] dt-bindings: power: rockchip: Convert to json-schema

2021-03-24 Thread Enric Balletbo i Serra

Hi Elaine,

This is not the exact version I sent, and you reintroduced a "problem" that were
already solved/discussed on previous versions. See below:

On 24/3/21 8:16, Elaine Zhang wrote:
> Convert the soc/rockchip/power_domain.txt binding document to
> json-schema and move to the power bindings directory.
> 
> Signed-off-by: Enric Balletbo i Serra 

If you do significant is a good practice shortly describe them within [] here.

> Signed-off-by: Elaine Zhang 

Note that my last version already had the

Reviewed-by: Rob Herring 

Which should be fine for merging (with probably only minor changes) and you
could maintain if you don't do significant changes, but that's not the case, as
I said, you are reintroducing one problem. Please review the comments already
received on this patchset or similar patchsets to avoid this.

> ---
>  .../power/rockchip,power-controller.yaml  | 284 ++
>  .../bindings/soc/rockchip/power_domain.txt| 136 -
>  2 files changed, 284 insertions(+), 136 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml 
> b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> new file mode 100644
> index ..a220322c5139
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> @@ -0,0 +1,284 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip Power Domains
> +
> +maintainers:
> +  - Elaine Zhang 
> +  - Rob Herring 

Up to Rob, but I don't think Rob would like to be the maintainer. I think you
can only include yourself and Heiko.


> +  - Heiko Stuebner 
> +
> +description: |
> +  Rockchip processors include support for multiple power domains which can be
> +  powered up/down by software based on different application scenarios to 
> save power.
> +
> +  Power domains contained within power-controller node are generic power 
> domain
> +  providers documented in 
> Documentation/devicetree/bindings/power/power-domain.yaml.
> +
> +  IP cores belonging to a power domain should contain a "power-domains"
> +  property that is a phandle for the power domain node representing the 
> domain.
> +
> +properties:
> +  $nodename:
> +const: power-controller
> +
> +  compatible:
> +enum:
> +  - rockchip,px30-power-controller
> +  - rockchip,rk3036-power-controller
> +  - rockchip,rk3066-power-controller
> +  - rockchip,rk3128-power-controller
> +  - rockchip,rk3188-power-controller
> +  - rockchip,rk3228-power-controller
> +  - rockchip,rk3288-power-controller
> +  - rockchip,rk3328-power-controller
> +  - rockchip,rk3366-power-controller
> +  - rockchip,rk3368-power-controller
> +  - rockchip,rk3399-power-controller
> +
> +  "#power-domain-cells":
> +const: 1
> +
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0
> +
> +patternProperties:
> +  "^pd_[0-9a-z_]{2,10}@[0-9a-f]+$":
> +type: object
> +description: |
> +  Represents the power domains within the power controller node as 
> documented
> +  in Documentation/devicetree/bindings/power/power-domain.yaml.
> +

The node names must be generic, as this is power-domain must be in the form:

+patternProperties:
+  "^power-domain@[0-9a-f]+$":


> +properties:
> +
> +  "#power-domain-cells":
> +description:
> +  Must be 0 for nodes representing a single PM domain and 1 for nodes
> +  providing multiple PM domains.
> +
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0
> +
> +  reg:
> +maxItems: 1
> +description: |
> +  Power domain index. Valid values are defined in
> +  "include/dt-bindings/power/px30-power.h"
> +  "include/dt-bindings/power/rk3036-power.h"
> +  "include/dt-bindings/power/rk3066-power.h"
> +  "include/dt-bindings/power/rk3128-power.h"
> +  "include/dt-bindings/power/rk3188-power.h"
> +  "include/dt-bindings/power/rk3228-power.h"
> +  "include/dt-bindings/power/rk3288-power.h"
> +  "include/dt-bindings/power/rk3328-power.h"
> +  "include/dt-bindings/power/rk3366-power.h"
> +  "include/dt-bindings/power/rk3368-power.h"
> +  "include/dt-bindings/power/rk3399-power.h"
> +
> +  clocks:
> +description: |
> +  A number of phandles to clocks that need to be enabled while power 
> domain
> +  switches state.
> +
> +  pm_qos:
> +description: |
> +  A number of phandles to qos blocks which need to be saved and 
> restored
>

Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

2021-03-24 Thread Daniel Vetter

On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:
> 
> On 3/23/21 5:37 PM, Jason Gunthorpe wrote:
> > On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote:
> > 
> > > > > @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct 
> > > > > vm_fault *vmf,
> > > > >   if ((pfn & (fault_page_size - 1)) != 0)
> > > > >   goto out_fallback;
> > > > > + /*
> > > > > +  * Huge entries must be special, that is marking them as devmap
> > > > > +  * with no backing device map range. If there is a backing
> > > > > +  * range, Don't insert a huge entry.
> > > > > +  * If this check turns out to be too much of a performance hit,
> > > > > +  * we can instead have drivers indicate whether they may have
> > > > > +  * backing device map ranges and if not, skip this lookup.
> > > > > +  */
> > > > I think we can do this statically:
> > > > - if it's system memory we know there's no devmap for it, and we do the
> > > > trick to block gup_fast
> > > Yes, that should work.
> > > > - if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV,
> > > > so might as well not do that
> > > I think gup_fast will unfortunately mistake a huge iomem page for an
> > > ordinary page and try to access a non-existant struct page for it, unless 
> > > we
> > > do the devmap trick.
> > > 
> > > And the lookup would then be for the rare case where a driver would have
> > > already registered a dev_pagemap for an iomem area which may also be 
> > > mapped
> > > through TTM (like the patch from Felix a couple of weeks ago). If a driver
> > > can promise not to do that, then we can safely remove the lookup.
> > Isn't the devmap PTE flag arch optional? Does this fall back to not
> > using huge pages on arches that don't support it?
> 
> Good point. No, currently it's only conditioned on transhuge page support.
> Need to condition it on also devmap support.
> 
> > 
> > Also, I feel like this code to install "pte_special" huge pages does
> > not belong in the drm subsystem..
> 
> I could add helpers in huge_memory.c:
> 
> vmf_insert_pfn_pmd_prot_special() and
> vmf_insert_pfn_pud_prot_special()

The somewhat annoying thing is that we'd need an error code so we fall
back to pte fault handling. That's at least my understanding of how
pud/pmd fault handling works. Not sure how awkward that is going to be
with the overall fault handling flow.

But aside from that I think this makes tons of sense.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 04/12] module: Add printk format to add module build ID to stacktraces

2021-03-24 Thread Rasmus Villemoes

On 24/03/2021 03.04, Stephen Boyd wrote:

> @@ -2778,6 +2793,10 @@ static inline void layout_symtab(struct module *mod, 
> struct load_info *info)
>  static void add_kallsyms(struct module *mod, const struct load_info *info)
>  {
>  }
> +
> +static void init_build_id(struct module *mod, const struct load_info *info)
> +{
> +}
>  #endif /* CONFIG_KALLSYMS */
>  
>  static void dynamic_debug_setup(struct module *mod, struct _ddebug *debug, 
> unsigned int num)
> @@ -4004,6 +4023,7 @@ static int load_module(struct load_info *info, const 
> char __user *uargs,
>   goto free_arch_cleanup;
>   }
>  
> + init_build_id(mod, info);
>   dynamic_debug_setup(mod, info->debug, info->num_debug);
>  
>   /* Ftrace init must be called in the MODULE_STATE_UNFORMED state */
> @@ -4235,7 +4255,7 @@ void * __weak 
> dereference_module_function_descriptor(struct module *mod,
>  const char *module_address_lookup(unsigned long addr,
>   unsigned long *size,
>   unsigned long *offset,
> - char **modname,
> + char **modname, unsigned char **modbuildid,

It's an existing defect with modname, but surely this should take a
"const unsigned char **modbuildid", no?

>   char *namebuf)
>  {
>   const char *ret = NULL;
> @@ -4246,6 +4266,8 @@ const char *module_address_lookup(unsigned long addr,
>   if (mod) {
>   if (modname)
>   *modname = mod->name;
> + if (modbuildid)
> + *modbuildid = mod->build_id;
>  
>   ret = find_kallsyms_symbol(mod, addr, size, offset);
>   }
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 41ddc353ebb8..9cd62e84e4aa 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -961,13 +961,15 @@ char *symbol_string(char *buf, char *end, void *ptr,
>   char sym[KSYM_SYMBOL_LEN];
>  #endif
>  
> - if (fmt[1] == 'R')
> + if (fmt[1] == 'R' || fmt[1] == 'r')
>   ptr = __builtin_extract_return_addr(ptr);
>   value = (unsigned long)ptr;
>  
>  #ifdef CONFIG_KALLSYMS
>   if (*fmt == 'B')
>   sprint_backtrace(sym, value);
> + else if (*fmt == 'S' && (fmt[1] == 'b' || fmt[1] == 'r'))
> + sprint_symbol_stacktrace(sym, value);
>   else if (*fmt != 's')
>   sprint_symbol(sym, value);
>   else
> @@ -2129,6 +2131,8 @@ early_param("no_hash_pointers", 
> no_hash_pointers_enable);
>   * - 'S' For symbolic direct pointers (or function descriptors) with offset
>   * - 's' For symbolic direct pointers (or function descriptors) without 
> offset
>   * - '[Ss]R' as above with __builtin_extract_return_addr() translation
> + * - '[Ss]r' as above with __builtin_extract_return_addr() translation and 
> module build ID
> + * - '[Ss]b' as above with module build ID (for use in backtraces)

The code doesn't quite match the comment. The lowercase s is not handled
(i.e., there's no way to say "without offset, with build ID"). You don't
have to fix the code to support that right now, the whole kallsyms
vsprintf code needs to be reworked inside-out anyway (having vsnprint
call sprint_symbol* which builds the output using snprintf() calls makes
me cringe), so please just replace [Ss] by S to make the comment match
the code - I notice that you did only document the S variant in
printk-formats.rst.

Is there any reason you didn't just make b an optional flag that could
be specified with or without R? I suppose the parsing is more difficult
with several orthogonal flags (see escaped_string()), but it's a little
easier to understand. Dunno, it's not like we're gonna think of 10 other
things that could be printed for a symbol, so perhaps it's fine.

Rasmus

Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st

2021-03-24 Thread Marc Kleine-Budde

On 24.03.2021 10:09:22, Oliver Hartkopp wrote:
> @Marc: Looks like we can not get around the __packed() fix :-(
> 
> At least we now have some more documentation to be referenced and I would
> suggest to point out that some compilers handle the union alignment like
> this.

It's not the compiler, but the ABI.

> To make clear in the comments what we are suppressing here any why.

Feel free to post an updated patch description.

Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature

Re: CHECKPATCH: missing a warning soon after include files decl -c

2021-03-24 Thread Fabio Aiuto

On Sat, Mar 20, 2021 at 04:28:51AM -0700, Joe Perches wrote:
> 
> Actually, these would seem to be better as one or multiple functions with
> local statics or even as static inlines functions in the .h file
> 
> $ git grep -w RTW_WPA_OUI drivers/staging/rtl8723bs/core
> drivers/staging/rtl8723bs/core/rtw_ap.c:extern unsigned char RTW_WPA_OUI[];
> drivers/staging/rtl8723bs/core/rtw_ap.c:if (!memcmp(RTW_WPA_OUI, oui, 
> 4))
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:unsigned char RTW_WPA_OUI[] = 
> {0x00, 0x50, 0xf2, 0x01};
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:  if 
> ((!memcmp(pIE->data, RTW_WPA_OUI, 4)) ||
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:extern unsigned char 
> RTW_WPA_OUI[];
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c: if 
> ((!memcmp(pIE->data, RTW_WPA_OUI, 4)) && (!memcmp((pIE->data + 12), 
> WPA_TKIP_CIPHER, 4)))
> 
> $ git grep -w WMM_OUI drivers/staging/rtl8723bs/core
> drivers/staging/rtl8723bs/core/rtw_ap.c:extern unsigned char WMM_OUI[];
> drivers/staging/rtl8723bs/core/rtw_ap.c:else if (!memcmp(WMM_OUI, 
> oui, 4))
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:unsigned char WMM_OUI[] = 
> {0x00, 0x50, 0xf2, 0x02};
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:
>   (!memcmp(pIE->data, WMM_OUI, 4)) ||
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:  if 
> (!memcmp(pIE->data, WMM_OUI, 4))
> drivers/staging/rtl8723bs/include/rtw_mlme_ext.h:extern unsigned char 
> WMM_OUI[];
> 
> $ git grep -w WPS_OUI drivers/staging/rtl8723bs/core
> drivers/staging/rtl8723bs/core/rtw_ap.c:extern unsigned char WPS_OUI[];
> drivers/staging/rtl8723bs/core/rtw_ap.c:else if (!memcmp(WPS_OUI, 
> oui, 4))
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:unsigned char WPS_OUI[] = 
> {0x00, 0x50, 0xf2, 0x04};
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:
>   (!memcmp(pIE->data, WPS_OUI, 4))) {
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:  if 
> ((!padapter->registrypriv.wifi_spec) && (!memcmp(pIE->data, WPS_OUI, 4))) {
> 
> $ git grep -w P2P_OUI drivers/staging/rtl8723bs/core
> drivers/staging/rtl8723bs/core/rtw_ap.c:extern unsigned char P2P_OUI[];
> drivers/staging/rtl8723bs/core/rtw_ap.c:else if (!memcmp(P2P_OUI, 
> oui, 4))
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:unsigned char P2P_OUI[] = 
> {0x50, 0x6F, 0x9A, 0x09};
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:  if (!memcmp(frame_body + 2, 
> P2P_OUI, 4)) {
> 
> So maybe something like the below (written in email client, maybe typos)
> 
> enum oui_type {
>   RTW_WPA,
>   WMM,
>   WPS,
>   P2P
> };
> 
> bool is_oui_type(const u8 *mem, enum oui_type type)
> {
>   static const u8 rtw_wpa[] = {0x00, 0x50, 0xf2, 0x01};
>   static const u8 wmm[] = {0x00, 0x50, 0xf2, 0x02};
>   static const u8 wps[] = {0x00, 0x50, 0xf2, 0x04};
>   static const u8 p2p[] = {0x50, 0x6F, 0x9A, 0x09};
> 
>   const u8 *oui;
> 
>   if (type == RTW_WPA)
>   oui = rtw_wpa;
>   else if (type == WMM)
>   oui = wmm;
>   else if (type == WPS)
>   oui = wps;
>   else if (type == P2P)
>   oui = p2p;
>   else
>   return false;
> 
>   return !memcmp(mem, oui, 4);
> }
> 
> so for instance the P2P uses would become
> 
>   else if (is_oui_type(oui, P2P))
> and
>   if (is_oui_type(frame_body + 2, P2P)) {
> 
> though I think 4 byte OUIs are just odd.
> 
> https://en.wikipedia.org/wiki/Organizationally_unique_identifier
> 
> An organizationally unique identifier (OUI) is a 24-bit number that uniquely 
> identifies a vendor, manufacturer, or other organization.
> 
> 
> 

Hi,

is that good? May I do the same for others ouis? One small inline for each oui 
type instead
of a switch...

diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c 
b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 3cd9c61eec99..7d31f359cf37 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -1664,7 +1664,7 @@ static void update_bcn_p2p_ie(struct adapter *padapter)
 
 static void update_bcn_vendor_spec_ie(struct adapter *padapter, u8 *oui)
 {
-   if (!memcmp(RTW_WPA_OUI, oui, 4))
+   if (is_rtw_wpa_oui(oui))
update_bcn_wpa_ie(padapter);
 
else if (!memcmp(WMM_OUI, oui, 4))
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 8aadcf72a7ba..e05f70e434a2 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -57,7 +57,6 @@ static u8 null_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
 /**
 OUI definitions for the vendor specific IE
 ***/
-unsigned char RTW_WPA_OUI[] = {0x00, 0x50, 0xf2, 0x01};
 unsigned char WMM_O

Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

2021-03-24 Thread Daniel Vetter

On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:
> 
> On 3/23/21 8:52 PM, Williams, Dan J wrote:
> > On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
> > > TTM sets up huge page-table-entries both to system- and device
> > > memory,
> > > and we don't want gup to assume there are always valid backing struct
> > > pages for these. For PTEs this is handled by setting the pte_special
> > > bit,
> > > but for the huge PUDs and PMDs, we have neither pmd_special nor
> > > pud_special. Normally, huge TTM entries are identified by looking at
> > > vma_is_special_huge(), but fast gup can't do that, so as an
> > > alternative
> > > define _devmap entries for which there are no backing dev_pagemap as
> > > special, update documentation and make huge TTM entries _devmap,
> > > after
> > > verifying that there is no backing dev_pagemap.
> > Please do not abuse p{m,u}d_devmap like this. I'm in the process of
> > removing get_devpagemap() from the gup-fast path [1]. Instead there
> > should be space for p{m,u}d_special in the page table entries (at least
> > for x86-64). So the fix is to remove that old assumption that huge
> > pages can never be special.
> > 
> > [1]:
> > http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.st...@dwillia2-desk3.amr.corp.intel.com
> > 
> Hmm, yes with that patch it will obviously not work as intended.
> 
> Given that, I think we'll need to disable the TTM huge pages for now until
> we can sort out and agree on using a page table entry bit.

Yeah :-/

I think going full pud/pmd_mkspecial should then also mesh well with
Jason's request to wrap it all up into a vmf_insert_* helper, so at least
it would all look rather pretty in the end.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [syzbot] KASAN: use-after-free Read in disk_part_iter_next (2)

2021-03-24 Thread syzbot

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an 
issue:
KASAN: use-after-free Read in bdgrab

==
BUG: KASAN: use-after-free in bdgrab+0x4c/0x50 fs/block_dev.c:929
Read of size 8 at addr 88801639a2a8 by task syz-executor.0/10133

CPU: 1 PID: 10133 Comm: syz-executor.0 Not tainted 5.12.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x141/0x1d7 lib/dump_stack.c:120
 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232
 __kasan_report mm/kasan/report.c:399 [inline]
 kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416
 bdgrab+0x4c/0x50 fs/block_dev.c:929
 first_partition+0xfa/0x230 block/partitions/core.c:538
 blk_drop_partitions+0xb5/0xf0 block/partitions/core.c:555
 bdev_disk_changed+0x238/0x430 fs/block_dev.c:1237
 __loop_clr_fd+0x7c7/0xff0 drivers/block/loop.c:1271
 lo_release+0x1ac/0x1f0 drivers/block/loop.c:1923
 __blkdev_put+0x54e/0x800 fs/block_dev.c:1579
 blkdev_put+0x92/0x580 fs/block_dev.c:1632
 blkdev_close+0x8c/0xb0 fs/block_dev.c:1640
 __fput+0x288/0x920 fs/file_table.c:280
 task_work_run+0xdd/0x1a0 kernel/task_work.c:140
 tracehook_notify_resume include/linux/tracehook.h:189 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:174 [inline]
 exit_to_user_mode_prepare+0x249/0x250 kernel/entry/common.c:208
 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
 syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:301
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x41926b
Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 
63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 
44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44
RSP: 002b:7fff13e6a990 EFLAGS: 0293 ORIG_RAX: 0003
RAX:  RBX: 0004 RCX: 0041926b
RDX:  RSI: 0001 RDI: 0003
RBP: 0001 R08:  R09: 001b2fb20070
R10:  R11: 0293 R12: 0056c9e0
R13: 0056c9e0 R14: 0056bf60 R15: 0001383c

Allocated by task 10136:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
 kasan_set_track mm/kasan/common.c:46 [inline]
 set_alloc_info mm/kasan/common.c:427 [inline]
 __kasan_slab_alloc+0x75/0x90 mm/kasan/common.c:460
 kasan_slab_alloc include/linux/kasan.h:223 [inline]
 slab_post_alloc_hook mm/slab.h:516 [inline]
 slab_alloc_node mm/slub.c:2907 [inline]
 slab_alloc mm/slub.c:2915 [inline]
 kmem_cache_alloc+0x155/0x370 mm/slub.c:2920
 bdev_alloc_inode+0x18/0x80 fs/block_dev.c:786
 alloc_inode+0x61/0x230 fs/inode.c:234
 new_inode_pseudo fs/inode.c:928 [inline]
 new_inode+0x27/0x2f0 fs/inode.c:957
 bdev_alloc+0x20/0x2f0 fs/block_dev.c:876
 add_partition+0x1ab/0x8a0 block/partitions/core.c:348
 bdev_add_partition+0xb6/0x130 block/partitions/core.c:451
 blkpg_do_ioctl+0x2d0/0x340 block/ioctl.c:43
 blkpg_ioctl block/ioctl.c:60 [inline]
 blkdev_ioctl+0x577/0x6d0 block/ioctl.c:548
 block_ioctl+0xf9/0x140 fs/block_dev.c:1658
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Freed by task 4849:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
 kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357
 kasan_slab_free mm/kasan/common.c:360 [inline]
 kasan_slab_free mm/kasan/common.c:325 [inline]
 __kasan_slab_free+0xf5/0x130 mm/kasan/common.c:367
 kasan_slab_free include/linux/kasan.h:199 [inline]
 slab_free_hook mm/slub.c:1562 [inline]
 slab_free_freelist_hook+0x92/0x210 mm/slub.c:1600
 slab_free mm/slub.c:3161 [inline]
 kmem_cache_free+0x8a/0x740 mm/slub.c:3177
 i_callback+0x3f/0x70 fs/inode.c:223
 rcu_do_batch kernel/rcu/tree.c:2559 [inline]
 rcu_core+0x74a/0x12f0 kernel/rcu/tree.c:2794
 __do_softirq+0x29b/0x9f6 kernel/softirq.c:345

Last potentially related work creation:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
 kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:345
 __call_rcu kernel/rcu/tree.c:3039 [inline]
 call_rcu+0xb1/0x740 kernel/rcu/tree.c:3114
 destroy_inode+0x129/0x1b0 fs/inode.c:289
 iput_final fs/inode.c:1654 [inline]
 iput.part.0+0x57e/0x810 fs/inode.c:1680
 iput+0x58/0x70 fs/inode.c:1670
 blk_drop_partitions+0x9d/0xf0 block/partitions/core.c:557
 bdev_disk_changed+0x238/0x430 fs/block_dev.c:1237
 loop_reread_partitions+0x29/0x50 drivers/block/loop.c:655
 loop_set_status+0x704/0x1050 drivers/block/loop.c:1418
 loop_set_status64 drivers/block/loop.c:1538 [inline]
 lo_ioctl+0x4ca/0x1620 drivers/block/loop.c:1706
 blkdev_ioctl+0x2a1/0x6d0 block/ioctl.c:583
 block_ioctl+0xf9/0x140 fs/block_dev.c:

Re: [PATCH] i915_vma: Rename vma_lookup to i915_vma_lookup

2021-03-24 Thread Daniel Vetter

On Tue, Mar 23, 2021 at 01:42:21PM +, Liam Howlett wrote:
> Use i915 prefix to avoid name collision with future vma_lookup() in mm.
> 
> Signed-off-by: Liam R. Howlett 
> Reviewed-by: Matthew Wilcox (Oracle) 

Applied to i915-gem-next branch for 5.13. We have a bit a branch shuffling
going on right now so unusal path, it should show up in linux-next through
drm-next hopefully this week still.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_vma.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index caa9b041616b..ee0028c697f6 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -230,7 +230,7 @@ vma_create(struct drm_i915_gem_object *obj,
>  }
>  
>  static struct i915_vma *
> -vma_lookup(struct drm_i915_gem_object *obj,
> +i915_vma_lookup(struct drm_i915_gem_object *obj,
>  struct i915_address_space *vm,
>  const struct i915_ggtt_view *view)
>  {
> @@ -278,7 +278,7 @@ i915_vma_instance(struct drm_i915_gem_object *obj,
>   GEM_BUG_ON(!atomic_read(&vm->open));
>  
>   spin_lock(&obj->vma.lock);
> - vma = vma_lookup(obj, vm, view);
> + vma = i915_vma_lookup(obj, vm, view);
>   spin_unlock(&obj->vma.lock);
>  
>   /* vma_create() will resolve the race if another creates the vma */
> -- 
> 2.30.0

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

2021-03-24 Thread Leon Romanovsky

On Mon, Mar 22, 2021 at 11:10:03AM -0600, Alex Williamson wrote:
> On Sun, 21 Mar 2021 10:40:55 +0200
> Leon Romanovsky  wrote:
> 
> > On Sat, Mar 20, 2021 at 08:59:42AM -0600, Alex Williamson wrote:
> > > On Sat, 20 Mar 2021 11:10:08 +0200
> > > Leon Romanovsky  wrote:  
> > > > On Fri, Mar 19, 2021 at 10:23:13AM -0600, Alex Williamson wrote:   
> > > > > 
> > > > > What if we taint the kernel or pci_warn() for cases where either all
> > > > > the reset methods are disabled, ie. 'echo none > reset_method', or any
> > > > > time a device specific method is disabled?
> > > > 
> > > > What does it mean "none"? Does it mean nothing supported? If yes, I 
> > > > think that
> > > > pci_warn() will be enough. At least for me, taint is usable during 
> > > > debug stages,
> > > > probably if device doesn't crash no one will look to see 
> > > > /proc/sys/kernel/tainted.  
> > > 
> > > "none" as implemented in this patch, clearing the enabled function
> > > reset methods.  
> > 
> > It is far from intuitive, the empty string will be easier to understand,
> > because "none" means no reset at all.
> 
> "No reset at all" is what "none" achieves, the
> pci_dev.reset_methods_enabled bitmap is cleared.  We can use an empty
> string, but I think we want a way to clear all enabled resets and a way
> to return it to the default.  I could see arguments for an empty string
> serving either purpose, so this version proposed explicitly using
> "none" and "default", as included in the ABI update.

I will stick with "default" only and leave "none" for something else.

> 
> > > > > I'd almost go so far as to prevent disabling a device specific reset
> > > > > altogether, but for example should a device specific reset that fixes
> > > > > an aspect of FLR behavior prevent using a bus reset?  I'd prefer in 
> > > > > that
> > > > > case if direct FLR were disabled via a device flag introduced with the
> > > > > quirk and the remaining resets can still be selected by preference.   
> > > > >  
> > > > 
> > > > I don't know enough to discuss the PCI details, but you raised good 
> > > > point.
> > > > This sysfs is user visible API that is presented as is from device point
> > > > of view. It can be easily run into problems if PCI/core doesn't work 
> > > > with
> > > > user's choice.
> > > >   
> > > > > 
> > > > > Theoretically all the other reset methods work and are available, it's
> > > > > only a policy decision which to use, right?
> > > > 
> > > > But this patch was presented as a way to overcome situations where
> > > > supported != working and user magically knows which reset type to set.  
> > > 
> > > It's not magic, the new sysfs attributes expose which resets are
> > > enabled and the order that they're used, the user can simply select the
> > > next one.  Being able to bypass a broken reset method is a helpful side
> > > effect of getting to select a preferred reset method.  
> > 
> > Magic in a sense that user has no idea what those resets mean, the
> > expectation is that he will blindly iterate till something works.
> 
> Which ought to actually be a safe thing to do.  We should have quirks to
> exclude resets that are known broken but still probe as present and I'd
> be perfectly fine if we issue a warning if the user disables all resets
> for a given device.
>  
> > > > If you want to take this patch to be policy decision tool,
> > > > it will need to accept "reset_type1,reset_type2,..." sort of input,
> > > > so fallback will work natively.  
> > > 
> > > I don't see that as a requirement.  We have fall-through support in the
> > > kernel, but for a given device we're really only ever going to make use
> > > of one of those methods.  If a user knows enough about a device to have
> > > a preference, I think it can be singular.  That also significantly
> > > simplifies the interface and supporting code.  Thanks,  
> > 
> > I'm struggling to get requirements from this thread. You talked about
> > policy decision to overtake fallback mechanism, Amey wanted to avoid
> > quirks.
> > 
> > Do you have an example of such devices or we are talking about
> > theoretical case?
> 
> Look at any device that already has a reset quirk and the process it
> took to get there.  Those are more than just theoretical cases.

So let's fix the process. The long standing kernel policy is that kernel
bugs (and missing quirk can be seen as such bug) should be fixed in the
kernel and not workaround by the users.

> 
> For policy preference, I already described how I've configured QEMU to
> prefer a bus reset rather than a PM reset due to lack of specification
> regarding the scope of a PM "soft reset".  This interface would allow a
> system policy to do that same thing.
> 
> I don't think anyone is suggesting this as a means to avoid quirks that
> would resolve reset issues and create the best default general behavior.
> This provides a mechanism to test various reset methods, and thereby
> identify broken methods, and set a policy.

Re: [PATCH] treewide: remove editor modelines and cruft

2021-03-24 Thread Geert Uytterhoeven

On Wed, Mar 24, 2021 at 10:58 AM Masahiro Yamada  wrote:
> The section "19) Editor modelines and other cruft" in
> Documentation/process/coding-style.rst clearly says,
> "Do not include any of these in source files."
>
> I recently receive a patch to explicitly add a new one.
>
> Let's do treewide cleanups, otherwise some people follow the existing
> code and attempt to upstream their favoriate editor setups.
>
> It is even nicer if scripts/checkpatch.pl can check it.
>
> If we like to impose coding style in an editor-independent manner,
> I think editorconfig (patch [1]) is a saner solution.
>
> [1] https://lore.kernel.org/lkml/20200703073143.423557-1-da...@kdrag0n.dev/
>
> Signed-off-by: Masahiro Yamada 

>  arch/m68k/atari/time.c|  7 ---

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

2021-03-24 Thread Intel

On 3/24/21 10:58 AM, Daniel Vetter wrote:

On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:

On 3/23/21 8:52 PM, Williams, Dan J wrote:

On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:

TTM sets up huge page-table-entries both to system- and device
memory,
and we don't want gup to assume there are always valid backing struct
pages for these. For PTEs this is handled by setting the pte_special
bit,
but for the huge PUDs and PMDs, we have neither pmd_special nor
pud_special. Normally, huge TTM entries are identified by looking at
vma_is_special_huge(), but fast gup can't do that, so as an
alternative
define _devmap entries for which there are no backing dev_pagemap as
special, update documentation and make huge TTM entries _devmap,
after
verifying that there is no backing dev_pagemap.

Please do not abuse p{m,u}d_devmap like this. I'm in the process of
removing get_devpagemap() from the gup-fast path [1]. Instead there
should be space for p{m,u}d_special in the page table entries (at least
for x86-64). So the fix is to remove that old assumption that huge
pages can never be special.

[1]:
http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.st...@dwillia2-desk3.amr.corp.intel.com

Hmm, yes with that patch it will obviously not work as intended.

Given that, I think we'll need to disable the TTM huge pages for now until
we can sort out and agree on using a page table entry bit.

Yeah :-/

I think going full pud/pmd_mkspecial should then also mesh well with
Jason's request to wrap it all up into a vmf_insert_* helper, so at least
it would all look rather pretty in the end.

Yes, I agree. Seems like the special (SW1) is available also for huge
page table entries on x86 AFAICT, although just not implemented.
Otherwise the SW bits appear completely used up.

The PTE size vmf_insert_pfn__xxx functions either insert one of devmap
or special. I think the only users of the huge insert functions apart
form TTM currently insert devmap so we should probably be able to do the
same, and then DRM / TTM wouldn't need to care at all about special or not.

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1502 matches

Mail list logo