* [PATCH net-next 01/16] net/bond: Delete driver and module versions
From: Leon Romanovsky @ 2020-02-20 14:58 UTC (permalink / raw)
To: David S. Miller, Jakub Kicinski; +Cc: Leon Romanovsky, linux-netdev
In-Reply-To: <20200220145855.255704-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
The in-kernel code has already unique version, which is based
on Linus's tag, update the bond driver to be consistent with that
version.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/net/bonding/bond_main.c | 4 +---
drivers/net/bonding/bonding_priv.h | 4 ++--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 48d5ec770b94..a808cb8d1aec 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4321,7 +4321,6 @@ static void bond_ethtool_get_drvinfo(struct net_device *bond_dev,
struct ethtool_drvinfo *drvinfo)
{
strlcpy(drvinfo->driver, DRV_NAME, sizeof(drvinfo->driver));
- strlcpy(drvinfo->version, DRV_VERSION, sizeof(drvinfo->version));
snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version), "%d",
BOND_ABI_VERSION);
}
@@ -5015,6 +5014,5 @@ static void __exit bonding_exit(void)
module_init(bonding_init);
module_exit(bonding_exit);
MODULE_LICENSE("GPL");
-MODULE_VERSION(DRV_VERSION);
-MODULE_DESCRIPTION(DRV_DESCRIPTION ", v" DRV_VERSION);
+MODULE_DESCRIPTION(DRV_DESCRIPTION);
MODULE_AUTHOR("Thomas Davis, tadavis@lbl.gov and many others");
diff --git a/drivers/net/bonding/bonding_priv.h b/drivers/net/bonding/bonding_priv.h
index 5a4d81a9437c..b80dd8499c85 100644
--- a/drivers/net/bonding/bonding_priv.h
+++ b/drivers/net/bonding/bonding_priv.h
@@ -14,12 +14,12 @@
#ifndef _BONDING_PRIV_H
#define _BONDING_PRIV_H
+#include <linux/vermagic.h>
-#define DRV_VERSION "3.7.1"
#define DRV_RELDATE "April 27, 2011"
#define DRV_NAME "bonding"
#define DRV_DESCRIPTION "Ethernet Channel Bonding Driver"
-#define bond_version DRV_DESCRIPTION ": v" DRV_VERSION " (" DRV_RELDATE ")\n"
+#define bond_version DRV_DESCRIPTION ": v" UTS_RELEASE " (" DRV_RELDATE ")\n"
#endif
--
2.24.1
^ permalink raw reply related
* [PATCH net-next 00/16] Clean driver, module and FW versions
From: Leon Romanovsky @ 2020-02-20 14:58 UTC (permalink / raw)
To: David S. Miller, Jakub Kicinski; +Cc: Leon Romanovsky, linux-netdev
From: Leon Romanovsky <leonro@mellanox.com>
Hi,
This is first patchset to netdev (already sent RDMA [1] and arch/um)
in attempt to unify the version management for in-tree kernel code.
The patches follow already accepted ethtool change [2] to set as
a default linux kernel version.
It allows us to remove driver version and present to the users unified
picture of driver version, which is similar to default MODULE_VERSION().
As part of this series, I deleted various creative attempts to mark
absence of FW. There is no need to set "N/A" in ethtool ->fw_version
field and it is enough to do not set it.
1.
The code is compile tested and passes 0-day kbuild.
2.
The proposed changes are based on commit:
2bb07f4e1d86 ("tc-testing: updated tdc tests for basic filter")
3.
WIP branch is [3].
[1] https://lore.kernel.org/linux-rdma/20200220071239.231800-1-leon@kernel.org/
[2] https://lore.kernel.org/linux-rdma/20200127072028.19123-1-leon@kernel.org/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=ethtool
Leon Romanovsky (16):
net/bond: Delete driver and module versions
net/dummy: Ditch driver and module versions
net/3com: Delete driver and module versions from 3com drivers
net/adaptec: Clean driver versions
net/aeroflex: Clean ethtool_info struct assignments
net/agere: Delete unneeded driver version
net/alacritech: Delete driver version
net/allwinner: Remove driver version
net/alteon: Properly report FW version
net/althera: Delete hardcoded driver version
net/amazon: Ensure that driver version is aligned to the linux kernel
net/amd: Remove useless driver version
net/apm: Remove useless driver version and properly mark lack of FW
net/aquantia: Delete module version
net/arc: Delete driver version
net/atheros: Clean atheros code from driver version
drivers/net/bonding/bond_main.c | 4 +---
drivers/net/bonding/bonding_priv.h | 4 ++--
drivers/net/dummy.c | 3 ---
drivers/net/ethernet/3com/3c509.c | 7 +------
drivers/net/ethernet/3com/3c515.c | 6 ++----
drivers/net/ethernet/3com/3c589_cs.c | 2 --
drivers/net/ethernet/3com/typhoon.c | 1 -
drivers/net/ethernet/adaptec/starfire.c | 11 +++++------
drivers/net/ethernet/aeroflex/greth.c | 2 --
drivers/net/ethernet/agere/et131x.c | 1 -
drivers/net/ethernet/agere/et131x.h | 1 -
drivers/net/ethernet/alacritech/slicoss.c | 3 ---
drivers/net/ethernet/allwinner/sun4i-emac.c | 2 --
drivers/net/ethernet/alteon/acenic.c | 5 ++---
.../net/ethernet/altera/altera_tse_ethtool.c | 1 -
drivers/net/ethernet/amazon/ena/ena_ethtool.c | 1 -
drivers/net/ethernet/amazon/ena/ena_netdev.c | 17 ++---------------
drivers/net/ethernet/amazon/ena/ena_netdev.h | 11 -----------
drivers/net/ethernet/amd/amd8111e.c | 5 +----
drivers/net/ethernet/amd/au1000_eth.c | 5 -----
drivers/net/ethernet/amd/nmclan_cs.c | 9 +++------
drivers/net/ethernet/amd/pcnet32.c | 7 -------
drivers/net/ethernet/amd/sunlance.c | 10 ----------
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 1 -
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 1 -
drivers/net/ethernet/amd/xgbe/xgbe.h | 1 -
drivers/net/ethernet/apm/xgene-v2/ethtool.c | 2 --
drivers/net/ethernet/apm/xgene-v2/main.c | 1 -
drivers/net/ethernet/apm/xgene-v2/main.h | 1 -
.../net/ethernet/apm/xgene/xgene_enet_ethtool.c | 2 --
.../net/ethernet/apm/xgene/xgene_enet_main.c | 1 -
.../net/ethernet/apm/xgene/xgene_enet_main.h | 1 -
drivers/net/ethernet/aquantia/atlantic/aq_cfg.h | 4 ----
.../net/ethernet/aquantia/atlantic/aq_common.h | 1 -
.../net/ethernet/aquantia/atlantic/aq_ethtool.c | 1 -
.../net/ethernet/aquantia/atlantic/aq_main.c | 1 -
drivers/net/ethernet/aquantia/atlantic/ver.h | 12 ------------
drivers/net/ethernet/arc/emac.h | 1 -
drivers/net/ethernet/arc/emac_arc.c | 2 --
drivers/net/ethernet/arc/emac_main.c | 1 -
drivers/net/ethernet/arc/emac_rockchip.c | 2 --
drivers/net/ethernet/atheros/atl1c/atl1c.h | 1 -
.../net/ethernet/atheros/atl1c/atl1c_ethtool.c | 2 --
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 5 -----
drivers/net/ethernet/atheros/atl1e/atl1e.h | 1 -
.../net/ethernet/atheros/atl1e/atl1e_ethtool.c | 2 --
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 4 ----
drivers/net/ethernet/atheros/atlx/atl1.c | 6 ------
drivers/net/ethernet/atheros/atlx/atl2.c | 10 ----------
49 files changed, 19 insertions(+), 166 deletions(-)
delete mode 100644 drivers/net/ethernet/aquantia/atlantic/ver.h
--
2.24.1
^ permalink raw reply
* Re: [PATCH 03/52] drm: add managed resources tied to drm_device
From: Laurent Pinchart @ 2020-02-20 14:58 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Daniel Vetter, Intel Graphics Development, Rafael J. Wysocki,
DRI Development, Daniel Vetter
In-Reply-To: <20200219181932.GA2852663@kroah.com>
Hi Greg,
On Wed, Feb 19, 2020 at 07:19:32PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> >> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> >>> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote:
> >>>> On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote:
> >>>>> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote:
> >>>>>> We have lots of these. And the cleanup code tends to be of dubious
> >>>>>> quality. The biggest wrong pattern is that developers use devm_, which
> >>>>>> ties the release action to the underlying struct device, whereas
> >>>>>> all the userspace visible stuff attached to a drm_device can long
> >>>>>> outlive that one (e.g. after a hotunplug while userspace has open
> >>>>>> files and mmap'ed buffers). Give people what they want, but with more
> >>>>>> correctness.
> >>>>>>
> >>>>>> Mostly copied from devres.c, with types adjusted to fit drm_device and
> >>>>>> a few simplifications - I didn't (yet) copy over everything. Since
> >>>>>> the types don't match code sharing looked like a hopeless endeavour.
> >>>>>>
> >>>>>> For now it's only super simplified, no groups, you can't remove
> >>>>>> actions (but kfree exists, we'll need that soon). Plus all specific to
> >>>>>> drm_device ofc, including the logging. Which I didn't bother to make
> >>>>>> compile-time optional, since none of the other drm logging is compile
> >>>>>> time optional either.
> >>>>>>
> >>>>>> One tricky bit here is the chicken&egg between allocating your
> >>>>>> drm_device structure and initiliazing it with drm_dev_init. For
> >>>>>> perfect onion unwinding we'd need to have the action to kfree the
> >>>>>> allocation registered before drm_dev_init registers any of its own
> >>>>>> release handlers. But drm_dev_init doesn't know where exactly the
> >>>>>> drm_device is emebedded into the overall structure, and by the time it
> >>>>>> returns it'll all be too late. And forcing drivers to be able clean up
> >>>>>> everything except the one kzalloc is silly.
> >>>>>>
> >>>>>> Work around this by having a very special final_kfree pointer. This
> >>>>>> also avoids troubles with the list head possibly disappearing from
> >>>>>> underneath us when we release all resources attached to the
> >>>>>> drm_device.
> >>>>>
> >>>>> This is all a very good idea ! Many subsystems are plagged by drivers
> >>>>> using devm_k*alloc to allocate data accessible by userspace. Since the
> >>>>> introduction of devm_*, we've likely reduced the number of memory leaks,
> >>>>> but I'm pretty sure we've increased the risk of crashes as I've seen
> >>>>> some drivers that used .release() callbacks correctly being naively
> >>>>> converted to incorrect devm_* usage :-(
> >>>>>
> >>>>> This leads me to a question: if other subsystems have the same problem,
> >>>>> could we turn this implementation into something more generic ? It
> >>>>> doesn't have to be done right away and shouldn't block merging this
> >>>>> series, but I think it would be very useful.
> >>>>
> >>>> It shouldn't be that hard to tie this into a drv_m() type of a thing
> >>>> (driver_memory?)
> >>>>
> >>>> And yes, I think it's much better than devm_* for the obvious reasons of
> >>>> this being needed here.
> >>>
> >>> There's two reasons I went with copypasta instead of trying to share code:
> >>> - Type checking, I definitely don't want people to mix up devm_ with
> >>> drmm_. But even if we do a drv_m that subsystems could embed we do
> >>> have quite a few different types of component drivers (and with
> >>> drm_panel and drm_bridge even standardized), and I don't want people
> >>> to be able to pass the wrong kind of struct to e.g. a managed
> >>> drmm_connector_init - it really needs to be the drm_device, not a
> >>> panel or bridge or something else.
> >>
> >> Fair enough, that makes sense.
> >>
> >>> - We could still share the code as a kind of implementation/backend
> >>> library. But it's not much, and with embedding I could use the drm
> >>> device logging stuff which is kinda nice. But if there's more demand
> >>> for this I can definitely see the point in sharing this, as Laurent
> >>> pointed out with the tiny optimization with not allocating a NULL void
> >>> * that I've done (and screwed up) it's not entirely trivial code.
> >>
> >> I think moving over time to having this be a backend library is good.
> >> But no rush/issues here with this going in now, it solves a real need
> >> and we can refactor it later on to try to make it more "bus/class"
> >> generic as needed.
> >
> > >From a type checking point of view, it would then be nice to have a
> > structure that models a device node, other than just struct device that
> > is shared by all types of devices. As someone who was involve in the
> > creation of the device model we have today, and thus know the history,
> > what's your opinion on that ?
>
> My opinion is that 'struct device' was created just for that exact
> thing. If "all you want" is a device node, it is trivial to use:
> device_create();
> or device_create_varargs() or device_create_with_groups()
> and then use device_destroy() when you are done with it.
>
> yes, it can do much more complex things, as needed, but the basics are
> there, so use it in a simple way if you want to, no objection from me.
>
> If there are things that are missing with it, please let me know.
I don't think it's really about anything missing, but about having two
different APIs for driver developers, to associate resources with either
physical devices that can disappear from the system, or with interfaces
exposed to userspace (or other parts of the kernel). The lifetime
constraints are very different, and if both cases are handled with the
devres API and a struct device, it's very easy for driver authors to
pass the wrong struct device to the API, tying the lifetime of a
userspace-facing resource with the physical device (this is what devres
is mostly used for today :-(). Having two different objects would make
it more apparent which API should be used, and would make it easier to
catch incorrect usage during review. I think this is Daniel's main
point, and the reason that prompted him to create a new API instead of
just reusing devres with the struct device that models the userspace
interface.
(On a side node, I wonder if devres shouldn't have been implemented at
the kref level.)
> But creating a new structure/way for this, no, we do not want to go back
> to the 2.4 and older kernel methods where it was all totally disjointed
> and messy.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
From: Laurent Pinchart @ 2020-02-20 14:58 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Daniel Vetter, Intel Graphics Development, Rafael J. Wysocki,
DRI Development, Daniel Vetter
In-Reply-To: <20200219181932.GA2852663@kroah.com>
Hi Greg,
On Wed, Feb 19, 2020 at 07:19:32PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> >> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> >>> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote:
> >>>> On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote:
> >>>>> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote:
> >>>>>> We have lots of these. And the cleanup code tends to be of dubious
> >>>>>> quality. The biggest wrong pattern is that developers use devm_, which
> >>>>>> ties the release action to the underlying struct device, whereas
> >>>>>> all the userspace visible stuff attached to a drm_device can long
> >>>>>> outlive that one (e.g. after a hotunplug while userspace has open
> >>>>>> files and mmap'ed buffers). Give people what they want, but with more
> >>>>>> correctness.
> >>>>>>
> >>>>>> Mostly copied from devres.c, with types adjusted to fit drm_device and
> >>>>>> a few simplifications - I didn't (yet) copy over everything. Since
> >>>>>> the types don't match code sharing looked like a hopeless endeavour.
> >>>>>>
> >>>>>> For now it's only super simplified, no groups, you can't remove
> >>>>>> actions (but kfree exists, we'll need that soon). Plus all specific to
> >>>>>> drm_device ofc, including the logging. Which I didn't bother to make
> >>>>>> compile-time optional, since none of the other drm logging is compile
> >>>>>> time optional either.
> >>>>>>
> >>>>>> One tricky bit here is the chicken&egg between allocating your
> >>>>>> drm_device structure and initiliazing it with drm_dev_init. For
> >>>>>> perfect onion unwinding we'd need to have the action to kfree the
> >>>>>> allocation registered before drm_dev_init registers any of its own
> >>>>>> release handlers. But drm_dev_init doesn't know where exactly the
> >>>>>> drm_device is emebedded into the overall structure, and by the time it
> >>>>>> returns it'll all be too late. And forcing drivers to be able clean up
> >>>>>> everything except the one kzalloc is silly.
> >>>>>>
> >>>>>> Work around this by having a very special final_kfree pointer. This
> >>>>>> also avoids troubles with the list head possibly disappearing from
> >>>>>> underneath us when we release all resources attached to the
> >>>>>> drm_device.
> >>>>>
> >>>>> This is all a very good idea ! Many subsystems are plagged by drivers
> >>>>> using devm_k*alloc to allocate data accessible by userspace. Since the
> >>>>> introduction of devm_*, we've likely reduced the number of memory leaks,
> >>>>> but I'm pretty sure we've increased the risk of crashes as I've seen
> >>>>> some drivers that used .release() callbacks correctly being naively
> >>>>> converted to incorrect devm_* usage :-(
> >>>>>
> >>>>> This leads me to a question: if other subsystems have the same problem,
> >>>>> could we turn this implementation into something more generic ? It
> >>>>> doesn't have to be done right away and shouldn't block merging this
> >>>>> series, but I think it would be very useful.
> >>>>
> >>>> It shouldn't be that hard to tie this into a drv_m() type of a thing
> >>>> (driver_memory?)
> >>>>
> >>>> And yes, I think it's much better than devm_* for the obvious reasons of
> >>>> this being needed here.
> >>>
> >>> There's two reasons I went with copypasta instead of trying to share code:
> >>> - Type checking, I definitely don't want people to mix up devm_ with
> >>> drmm_. But even if we do a drv_m that subsystems could embed we do
> >>> have quite a few different types of component drivers (and with
> >>> drm_panel and drm_bridge even standardized), and I don't want people
> >>> to be able to pass the wrong kind of struct to e.g. a managed
> >>> drmm_connector_init - it really needs to be the drm_device, not a
> >>> panel or bridge or something else.
> >>
> >> Fair enough, that makes sense.
> >>
> >>> - We could still share the code as a kind of implementation/backend
> >>> library. But it's not much, and with embedding I could use the drm
> >>> device logging stuff which is kinda nice. But if there's more demand
> >>> for this I can definitely see the point in sharing this, as Laurent
> >>> pointed out with the tiny optimization with not allocating a NULL void
> >>> * that I've done (and screwed up) it's not entirely trivial code.
> >>
> >> I think moving over time to having this be a backend library is good.
> >> But no rush/issues here with this going in now, it solves a real need
> >> and we can refactor it later on to try to make it more "bus/class"
> >> generic as needed.
> >
> > >From a type checking point of view, it would then be nice to have a
> > structure that models a device node, other than just struct device that
> > is shared by all types of devices. As someone who was involve in the
> > creation of the device model we have today, and thus know the history,
> > what's your opinion on that ?
>
> My opinion is that 'struct device' was created just for that exact
> thing. If "all you want" is a device node, it is trivial to use:
> device_create();
> or device_create_varargs() or device_create_with_groups()
> and then use device_destroy() when you are done with it.
>
> yes, it can do much more complex things, as needed, but the basics are
> there, so use it in a simple way if you want to, no objection from me.
>
> If there are things that are missing with it, please let me know.
I don't think it's really about anything missing, but about having two
different APIs for driver developers, to associate resources with either
physical devices that can disappear from the system, or with interfaces
exposed to userspace (or other parts of the kernel). The lifetime
constraints are very different, and if both cases are handled with the
devres API and a struct device, it's very easy for driver authors to
pass the wrong struct device to the API, tying the lifetime of a
userspace-facing resource with the physical device (this is what devres
is mostly used for today :-(). Having two different objects would make
it more apparent which API should be used, and would make it easier to
catch incorrect usage during review. I think this is Daniel's main
point, and the reason that prompted him to create a new API instead of
just reusing devres with the struct device that models the userspace
interface.
(On a side node, I wonder if devres shouldn't have been implemented at
the kref level.)
> But creating a new structure/way for this, no, we do not want to go back
> to the 2.4 and older kernel methods where it was all totally disjointed
> and messy.
--
Regards,
Laurent Pinchart
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 11/19] afs: Support fsinfo() [ver #16]
From: Jann Horn @ 2020-02-20 14:58 UTC (permalink / raw)
To: David Howells
Cc: Al Viro, raven, Miklos Szeredi, Christian Brauner, Linux API,
linux-fsdevel, kernel list
In-Reply-To: <628199.1582203532@warthog.procyon.org.uk>
On Thu, Feb 20, 2020 at 1:59 PM David Howells <dhowells@redhat.com> wrote:
> Jann Horn <jannh@google.com> wrote:
>
> > Ewww. So basically, having one static set of .fsinfo_attributes is not
> > sufficiently flexible for everyone, but instead of allowing the
> > filesystem to dynamically provide a list of supported attributes, you
> > just duplicate the super_operations? Seems to me like it'd be cleaner
> > to add a function pointer to the super_operations that can dynamically
> > fill out the supported fsinfo attributes.
> >
> > It seems to me like the current API is going to be a dead end if you
> > ever want to have decent passthrough of these things for e.g. FUSE, or
> > overlayfs, or VirtFS?
>
> Ummm...
>
> Would it be sufficient to have a function that returns a list of attributes?
> Or does it need to be able to call to vfs_do_fsinfo() if it supports an
> attribute?
>
> There are two things I want to be able to do:
>
> (1) Do the buffer wrangling in the core - which means the core needs to see
> the type of the attribute. That's fine if, say, afs_fsinfo() can call
> vfs_do_fsinfo() with the definition for any attribute it wants to handle
> and, say, return -ENOPKG otherways so that the core can then fall back to
> its private list.
>
> (2) Be able to retrieve the list of attributes and/or query an attribute.
> Now, I can probably manage this even through the same interface. If,
> say, seeing FSINFO_ATTR_FSINFO_ATTRIBUTES causes the handler to simply
> append on the IDs of its own supported attributes (a helper can be
> provided for that).
>
> If it sees FSINFO_ATR_FSINFO_ATTRIBUTE_INFO, it can just look to see if
> it has the attribute with the ID matching Nth and return that, else
> ENOPKG - again a helper could be provided.
>
> Chaining through overlayfs gets tricky. You end up with multiple contributory
> filesystems with different properties - and any one of those layers could
> perhaps be another overlay. Overlayfs would probably needs to integrate the
> info and derive the lowest common set.
Hm - I guess just returning a list of attributes ought to be fine?
Then AFS can just return one of its two statically-allocated attribute
lists there, and a filesystem with more complicated circumstances
(like FUSE or overlayfs or whatever) can compute a heap-allocated list
on mount that is freed when the superblock goes away, or something
like that?
^ permalink raw reply
* Re: S variable for svn fetcher Was: State of OE world - 2020-02-18
From: Tom Rini @ 2020-02-20 14:57 UTC (permalink / raw)
To: Martin Jansa; +Cc: openembeded-devel
In-Reply-To: <20200220144848.msiyguq2bsmqokxc@jama>
On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> On Wed, Feb 19, 2020 at 09:29:58AM -0800, Khem Raj wrote:
> > http://www.openembedded.org/wiki/Bitbake_World_Status
> >
> > == Failed tasks /media/ra_build_share/buildlogs/oe/world/dunfell/2020-02-18 ==
> >
> > INFO: jenkins-job.sh-1.8.46 Complete log available at
> > /media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.report.20200219_150007.log
> >
> > === common (0) ===
> >
> > === common-x86 (0) ===
> >
> > === qemuarm (0) ===
> >
> > === qemuarm64 (0) ===
> >
> > === qemux86 (0) ===
> >
> > === qemux86_64 (0) ===
>
> Looks great! Thanks
>
> I was running some world builds recently as well and was surprised that
> there are a few failing recipes in meta-oe:
> s3c24xx-gpio
> s3c64xx-gpio
> wmiconfig
> usbpath
> which are all using svn fetcher.
>
> Any idea why these aren't shown in our build? I was able to reproduce
> this on thud as well as latest master build:
>
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/usbpath/usbpath_svn.bb:do_patch
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_compile
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_compile
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_populate_lic
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_populate_lic
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/wmiconfig/wmiconfig_svn.bb:do_patch
>
> they have all the same root cause and that is that the
> S variable points to directory where the sources used to be, but now
> they are checked out somewhere else, e.g. s3c24xx-gpio:
>
> LIC_FILES_CHKSUM = "file://gpio.c;endline=12;md5=cfb91c686857b2e60852b4925d90a3e1"
>
> SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
>
> S = "${WORKDIR}/gpio"
>
> And now S looks like this:
> $ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/
> branches trunk
>
> While before I believe it was checking out just this directory (as ${WORKDIR}/gpio):
> $ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/trunk/src/target/gpio/
> gpio.c gpio-glamo.c gpio-s3c6410.c Makefile README
>
> Anyone still actively using svn fetcher for something?
>
> I'll check with even older bitbake to see when it changed, but it's
> still surprising that you wouldn't be seeing it with latest bitbake
> in world builds.
Chiming in as this caught my eye. I've run in to this perhaps with
'warrior' as well recently for a customer. I assumed it was just that
it had been so long since I had used SVN I had just mis-remembered how
S needed to be set. I also as a tangent noticed that AUTOREV for svn
seems broken as it doesn't ensure we have subversion-native in the
sysroot ('svn command not found' is the relevant part of the failure).
--
Tom
^ permalink raw reply
* [Buildroot] [PATCH v2 1/1] package/avahi: bump to version 0.8
From: Thomas Petazzoni @ 2020-02-20 14:56 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20200220091526.232214-1-joerg.krause@embedded.rocks>
On Thu, 20 Feb 2020 10:15:26 +0100
J?rg Krause <joerg.krause@embedded.rocks> wrote:
> This bump also includes:
> * Drop upstream security patch which is included in the new version
> * Unconditionally disable support for Qt5 [1] (same as Qt3 and Qt4)
> * Drop dependency on host-inttool, as avahi switched to host-gettext [2]
> * Conditionally enable support for libevent [3]
> * Drop disabling support for Qt3, Qt4, and GTK, which are disabled by
> default now
>
> [1] https://github.com/lathiat/avahi/commit/5dbb32767ae3f5a371cfbd04b4e3a9a634b8efc4
> [2] https://github.com/lathiat/avahi/commit/3d5a0c68057e2ed76187a0bb565baaa10d566003
> [3] https://github.com/lathiat/avahi/commit/998e20cd76927ce978fb5676820a38308e21f45d
>
> Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> ---
> v2 [suggested by Thomas Petazzoni]:
Thanks!
> * host-gettext (as replacement for host-intltool) is not needed
> * drop disabling support for Qt3, Qt4, and GTK, which are already
> disabled by default
Even if they are disabled by default, it's good to disable them
explicitly in the .mk file. My question in my previous review was more
"do they really still have qt3 support ?". But besides that I'm all for
keeping the --disable-<foo> for explicitly disabling features we don't
support.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 0/4] target/arm vector improvements
From: Peter Maydell @ 2020-02-20 14:55 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-arm, QEMU Developers
In-Reply-To: <20200216214232.4230-1-richard.henderson@linaro.org>
On Sun, 16 Feb 2020 at 21:42, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Changes for v2:
>
> * Rename function arguments as requested by ajb.
> * Minor optimization in helper_gvec_pmul_b.
>
> Original blurb:
>
> The first patch has been seen before.
>
> https://patchwork.ozlabs.org/patch/1115039/
>
> It had a bug and I didn't fix it right away and then forgot.
> Fixed now; I had mixed up the operand ordering for aarch32.
>
> The next 3 are something that I noticed while doing other stuff.
>
> In particular, pmull is used heavily during https transfers.
> While cloning a repository, the old code peaks at 27% of the
> total runtime, as measured by perf top. The new code does
> not quite reach 3% repeating the same clone.
>
> In addition, the new helper functions are in the form that
> will be required for the implementation of SVE2.
Applied to target-arm.next, thanks.
-- PMM
^ permalink raw reply
* Re: [RFC PATCH 0/3] efi: put an API version number in the PE/COFF header
From: Heinrich Schuchardt @ 2020-02-20 14:55 UTC (permalink / raw)
To: Ard Biesheuvel, linux-efi
Cc: lersek, leif, pjones, mjg59, agraf, ilias.apalodimas,
daniel.kiper, nivedita, James.Bottomley
In-Reply-To: <20200220110649.1303-1-ardb@kernel.org>
On 2/20/20 12:06 PM, Ard Biesheuvel wrote:
> After having added new ways to load the initrd and the mixed mode kernel,
> we will need to tell the loader about this, so it can use the new, generic
> method if supported, and fall back to the existing method(s) otherwise.
>
> This is an RFC - if there are better ways to record this in the image
> somehow, please shout.
Hello Ard,
for boot loaders like GRUB I understand that the boot loader could use
the initrd file path from its scripts to prepare a
EFI_LOAD_FILE2_PROTOCOL matching the loaded kernel.
I am not sure about the requirements for a firmware.
Up to now the U-Boot UEFI sub-system does not care about initial RAM
disk images at all. With Ilias suggested patch series U-Boot could offer
a file from a fixed file location via a EFI_LOAD_FILE2_PROTOCOL.
Is there anything else you expect a firmware like U-Boot or EDK2 to do?
Best regards
Heinrich
>
> Cc: lersek@redhat.com
> Cc: leif@nuviainc.com
> Cc: pjones@redhat.com
> Cc: mjg59@google.com
> Cc: agraf@csgraf.de
> Cc: ilias.apalodimas@linaro.org
> Cc: xypron.glpk@gmx.de
> Cc: daniel.kiper@oracle.com
> Cc: nivedita@alum.mit.edu
> Cc: James.Bottomley@hansenpartnership.com
>
> Ard Biesheuvel (3):
> efi/x86: Use symbolic constants in PE header instead of bare numbers
> efi/libstub: Introduce symbolic constants for the stub major/minor
> version
> efi: Bump the Linux EFI stub major version number to #1
>
> arch/arm/boot/compressed/efi-header.S | 4 +-
> arch/arm64/kernel/efi-header.S | 4 +-
> arch/x86/boot/header.S | 64 ++++++++++----------
> include/linux/pe.h | 21 +++++++
> 4 files changed, 58 insertions(+), 35 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 4/6] NFS: Add READ_PLUS data segment support
From: Chuck Lever @ 2020-02-20 14:55 UTC (permalink / raw)
To: Anna Schumaker; +Cc: Trond.Myklebust, Linux NFS Mailing List
In-Reply-To: <7621b7d84295dd3086e2036f8cb389ceb47cbbc2.camel@gmail.com>
> On Feb 20, 2020, at 9:42 AM, Anna Schumaker <schumaker.anna@gmail.com> wrote:
>
> On Fri, 2020-02-14 at 17:28 -0500, Chuck Lever wrote:
>>> On Feb 14, 2020, at 4:12 PM, schumaker.anna@gmail.com wrote:
>>>
>>> From: Anna Schumaker <Anna.Schumaker@Netapp.com>
>>>
>>> This patch adds client support for decoding a single NFS4_CONTENT_DATA
>>> segment returned by the server. This is the simplest implementation
>>> possible, since it does not account for any hole segments in the reply.
>>>
>>> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
>>> ---
>>> fs/nfs/nfs42xdr.c | 138 ++++++++++++++++++++++++++++++++++++++
>>> fs/nfs/nfs4proc.c | 43 +++++++++++-
>>> fs/nfs/nfs4xdr.c | 1 +
>>> include/linux/nfs4.h | 2 +-
>>> include/linux/nfs_fs_sb.h | 1 +
>>> include/linux/nfs_xdr.h | 2 +-
>>> 6 files changed, 182 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/nfs/nfs42xdr.c b/fs/nfs/nfs42xdr.c
>>> index c03f3246d6c5..bf118ecabe2c 100644
>>> --- a/fs/nfs/nfs42xdr.c
>>> +++ b/fs/nfs/nfs42xdr.c
>>> @@ -45,6 +45,15 @@
>>> #define encode_deallocate_maxsz (op_encode_hdr_maxsz + \
>>> encode_fallocate_maxsz)
>>> #define decode_deallocate_maxsz (op_decode_hdr_maxsz)
>>> +#define encode_read_plus_maxsz (op_encode_hdr_maxsz + \
>>> + encode_stateid_maxsz + 3)
>>> +#define NFS42_READ_PLUS_SEGMENT_SIZE (1 /* data_content4 */ + \
>>> + 2 /* data_info4.di_offset */ + \
>>> + 2 /* data_info4.di_length */)
>>> +#define decode_read_plus_maxsz (op_decode_hdr_maxsz + \
>>> + 1 /* rpr_eof */ + \
>>> + 1 /* rpr_contents count */ + \
>>> + NFS42_READ_PLUS_SEGMENT_SIZE)
>>> #define encode_seek_maxsz (op_encode_hdr_maxsz + \
>>> encode_stateid_maxsz + \
>>> 2 /* offset */ + \
>>> @@ -128,6 +137,14 @@
>>> decode_putfh_maxsz + \
>>> decode_deallocate_maxsz + \
>>> decode_getattr_maxsz)
>>> +#define NFS4_enc_read_plus_sz (compound_encode_hdr_maxsz + \
>>> + encode_sequence_maxsz + \
>>> + encode_putfh_maxsz + \
>>> + encode_read_plus_maxsz)
>>> +#define NFS4_dec_read_plus_sz (compound_decode_hdr_maxsz + \
>>> + decode_sequence_maxsz + \
>>> + decode_putfh_maxsz + \
>>> + decode_read_plus_maxsz)
>>> #define NFS4_enc_seek_sz (compound_encode_hdr_maxsz + \
>>> encode_sequence_maxsz + \
>>> encode_putfh_maxsz + \
>>> @@ -252,6 +269,16 @@ static void encode_deallocate(struct xdr_stream *xdr,
>>> encode_fallocate(xdr, args);
>>> }
>>>
>>> +static void encode_read_plus(struct xdr_stream *xdr,
>>> + const struct nfs_pgio_args *args,
>>> + struct compound_hdr *hdr)
>>> +{
>>> + encode_op_hdr(xdr, OP_READ_PLUS, decode_read_plus_maxsz, hdr);
>>> + encode_nfs4_stateid(xdr, &args->stateid);
>>> + encode_uint64(xdr, args->offset);
>>> + encode_uint32(xdr, args->count);
>>> +}
>>> +
>>> static void encode_seek(struct xdr_stream *xdr,
>>> const struct nfs42_seek_args *args,
>>> struct compound_hdr *hdr)
>>> @@ -446,6 +473,29 @@ static void nfs4_xdr_enc_deallocate(struct rpc_rqst
>>> *req,
>>> encode_nops(&hdr);
>>> }
>>>
>>> +/*
>>> + * Encode READ_PLUS request
>>> + */
>>> +static void nfs4_xdr_enc_read_plus(struct rpc_rqst *req,
>>> + struct xdr_stream *xdr,
>>> + const void *data)
>>> +{
>>> + const struct nfs_pgio_args *args = data;
>>> + struct compound_hdr hdr = {
>>> + .minorversion = nfs4_xdr_minorversion(&args->seq_args),
>>> + };
>>> +
>>> + encode_compound_hdr(xdr, req, &hdr);
>>> + encode_sequence(xdr, &args->seq_args, &hdr);
>>> + encode_putfh(xdr, args->fh, &hdr);
>>> + encode_read_plus(xdr, args, &hdr);
>>> +
>>> + rpc_prepare_reply_pages(req, args->pages, args->pgbase,
>>> + args->count, hdr.replen);
>>> + req->rq_rcv_buf.flags |= XDRBUF_READ;
>>
>> IMO this line is incorrect.
>
> You're right, this line causes problems for RDMA with READ_PLUS. I added it to
> match how the other xdr read encoders were set up
Ja, I think just removing that line should be sufficient.
Better would be replacing it with a comment explaining
why this encoder does not set XDRBUF_READ. :-)
>> RFC 8267 Section 6.1 does not list any part of the result of READ_PLUS
>> as DDP-eligible. There's no way for a client to know how to set up
>> Write chunks, unless it knows exactly where the file's holes are in
>> advance. Even then... racy.
>>
>> Just curious, have you tried READ_PLUS with proto=rdma ?
>
> I haven't done in-depth performance testing, but I have been able to run it.
We should figure out whether that will have a regressive
impact on NFS/RDMA workloads. I expect that it will, but
the client can always set up the Reply chunk so that the
READ payload fits precisely in an RDMA segment that lines
up with page cache pages. That mitigates some impact.
If your patch set already changes NFSv4.2 mounts to always
use READ_PLUS in place of READ, it might be prudent for the
"proto=rdma" mount option to also set "noreadplus", at least
for the time being.
The down-side here is that would make NFSv4.2 on RDMA
unable to recognize holes in files the same way as it
does on TCP, and that's a pretty significant variation
in behavior. Does "noreadplus" even deal with that?
> Anna
>
>>
>>
>>> + encode_nops(&hdr);
>>> +}
>>> +
>>> /*
>>> * Encode SEEK request
>>> */
>>> @@ -694,6 +744,67 @@ static int decode_deallocate(struct xdr_stream *xdr,
>>> struct nfs42_falloc_res *re
>>> return decode_op_hdr(xdr, OP_DEALLOCATE);
>>> }
>>>
>>> +static uint32_t decode_read_plus_data(struct xdr_stream *xdr, struct
>>> nfs_pgio_res *res,
>>> + uint32_t *eof)
>>> +{
>>> + __be32 *p;
>>> + uint32_t count, recvd;
>>> + uint64_t offset;
>>> +
>>> + p = xdr_inline_decode(xdr, 8 + 4);
>>> + if (unlikely(!p))
>>> + return -EIO;
>>> +
>>> + p = xdr_decode_hyper(p, &offset);
>>> + count = be32_to_cpup(p);
>>> + if (count == 0)
>>> + return 0;
>>> +
>>> + recvd = xdr_read_pages(xdr, count);
>>> + if (count > recvd) {
>>> + dprintk("NFS: server cheating in read reply: "
>>> + "count %u > recvd %u\n", count, recvd);
>>> + count = recvd;
>>> + *eof = 0;
>>> + }
>>> +
>>> + return count;
>>> +}
>>> +
>>> +static int decode_read_plus(struct xdr_stream *xdr, struct nfs_pgio_res
>>> *res)
>>> +{
>>> + __be32 *p;
>>> + uint32_t count, eof, segments, type;
>>> + int status;
>>> +
>>> + status = decode_op_hdr(xdr, OP_READ_PLUS);
>>> + if (status)
>>> + return status;
>>> +
>>> + p = xdr_inline_decode(xdr, 4 + 4);
>>> + if (unlikely(!p))
>>> + return -EIO;
>>> +
>>> + eof = be32_to_cpup(p++);
>>> + segments = be32_to_cpup(p++);
>>> + if (segments == 0)
>>> + return 0;
>>> +
>>> + p = xdr_inline_decode(xdr, 4);
>>> + if (unlikely(!p))
>>> + return -EIO;
>>> +
>>> + type = be32_to_cpup(p++);
>>> + if (type == NFS4_CONTENT_DATA)
>>> + count = decode_read_plus_data(xdr, res, &eof);
>>> + else
>>> + return -EINVAL;
>>> +
>>> + res->eof = eof;
>>> + res->count = count;
>>> + return 0;
>>> +}
>>> +
>>> static int decode_seek(struct xdr_stream *xdr, struct nfs42_seek_res *res)
>>> {
>>> int status;
>>> @@ -870,6 +981,33 @@ static int nfs4_xdr_dec_deallocate(struct rpc_rqst
>>> *rqstp,
>>> return status;
>>> }
>>>
>>> +/*
>>> + * Decode READ_PLUS request
>>> + */
>>> +static int nfs4_xdr_dec_read_plus(struct rpc_rqst *rqstp,
>>> + struct xdr_stream *xdr,
>>> + void *data)
>>> +{
>>> + struct nfs_pgio_res *res = data;
>>> + struct compound_hdr hdr;
>>> + int status;
>>> +
>>> + status = decode_compound_hdr(xdr, &hdr);
>>> + if (status)
>>> + goto out;
>>> + status = decode_sequence(xdr, &res->seq_res, rqstp);
>>> + if (status)
>>> + goto out;
>>> + status = decode_putfh(xdr);
>>> + if (status)
>>> + goto out;
>>> + status = decode_read_plus(xdr, res);
>>> + if (!status)
>>> + status = res->count;
>>> +out:
>>> + return status;
>>> +}
>>> +
>>> /*
>>> * Decode SEEK request
>>> */
>>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>>> index 95d07a3dc5d1..ed3ec8c36273 100644
>>> --- a/fs/nfs/nfs4proc.c
>>> +++ b/fs/nfs/nfs4proc.c
>>> @@ -69,6 +69,10 @@
>>>
>>> #include "nfs4trace.h"
>>>
>>> +#ifdef CONFIG_NFS_V4_2
>>> +#include "nfs42.h"
>>> +#endif /* CONFIG_NFS_V4_2 */
>>> +
>>> #define NFSDBG_FACILITY NFSDBG_PROC
>>>
>>> #define NFS4_BITMASK_SZ 3
>>> @@ -5199,28 +5203,60 @@ static bool nfs4_read_stateid_changed(struct
>>> rpc_task *task,
>>> return true;
>>> }
>>>
>>> +static bool nfs4_read_plus_not_supported(struct rpc_task *task,
>>> + struct nfs_pgio_header *hdr)
>>> +{
>>> + struct nfs_server *server = NFS_SERVER(hdr->inode);
>>> + struct rpc_message *msg = &task->tk_msg;
>>> +
>>> + if (msg->rpc_proc == &nfs4_procedures[NFSPROC4_CLNT_READ_PLUS] &&
>>> + server->caps & NFS_CAP_READ_PLUS && task->tk_status == -ENOTSUPP) {
>>> + server->caps &= ~NFS_CAP_READ_PLUS;
>>> + msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
>>> + rpc_restart_call_prepare(task);
>>> + return true;
>>> + }
>>> + return false;
>>> +}
>>> +
>>> static int nfs4_read_done(struct rpc_task *task, struct nfs_pgio_header
>>> *hdr)
>>> {
>>> -
>>> dprintk("--> %s\n", __func__);
>>>
>>> if (!nfs4_sequence_done(task, &hdr->res.seq_res))
>>> return -EAGAIN;
>>> if (nfs4_read_stateid_changed(task, &hdr->args))
>>> return -EAGAIN;
>>> + if (nfs4_read_plus_not_supported(task, hdr))
>>> + return -EAGAIN;
>>> if (task->tk_status > 0)
>>> nfs_invalidate_atime(hdr->inode);
>>> return hdr->pgio_done_cb ? hdr->pgio_done_cb(task, hdr) :
>>> nfs4_read_done_cb(task, hdr);
>>> }
>>>
>>> +#ifdef CONFIG_NFS_V4_2
>>> +static void nfs42_read_plus_support(struct nfs_server *server, struct
>>> rpc_message *msg)
>>> +{
>>> + if (server->caps & NFS_CAP_READ_PLUS)
>>> + msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ_PLUS];
>>> + else
>>> + msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
>>> +}
>>> +#else
>>> +static void nfs42_read_plus_support(struct nfs_server *server, struct
>>> rpc_message *msg)
>>> +{
>>> + msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
>>> +}
>>> +#endif /* CONFIG_NFS_V4_2 */
>>> +
>>> static void nfs4_proc_read_setup(struct nfs_pgio_header *hdr,
>>> struct rpc_message *msg)
>>> {
>>> hdr->timestamp = jiffies;
>>> if (!hdr->pgio_done_cb)
>>> hdr->pgio_done_cb = nfs4_read_done_cb;
>>> - msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
>>> + nfs42_read_plus_support(NFS_SERVER(hdr->inode), msg);
>>> nfs4_init_sequence(&hdr->args.seq_args, &hdr->res.seq_res, 0, 0);
>>> }
>>>
>>> @@ -9970,7 +10006,8 @@ static const struct nfs4_minor_version_ops
>>> nfs_v4_2_minor_ops = {
>>> | NFS_CAP_SEEK
>>> | NFS_CAP_LAYOUTSTATS
>>> | NFS_CAP_CLONE
>>> - | NFS_CAP_LAYOUTERROR,
>>> + | NFS_CAP_LAYOUTERROR
>>> + | NFS_CAP_READ_PLUS,
>>> .init_client = nfs41_init_client,
>>> .shutdown_client = nfs41_shutdown_client,
>>> .match_stateid = nfs41_match_stateid,
>>> diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
>>> index 47817ef0aadb..68b2917d0537 100644
>>> --- a/fs/nfs/nfs4xdr.c
>>> +++ b/fs/nfs/nfs4xdr.c
>>> @@ -7584,6 +7584,7 @@ const struct rpc_procinfo nfs4_procedures[] = {
>>> PROC42(COPY_NOTIFY, enc_copy_notify, dec_copy_notify),
>>> PROC(LOOKUPP, enc_lookupp, dec_lookupp),
>>> PROC42(LAYOUTERROR, enc_layouterror, dec_layouterror),
>>> + PROC42(READ_PLUS, enc_read_plus, dec_read_plus),
>>> };
>>>
>>> static unsigned int nfs_version4_counts[ARRAY_SIZE(nfs4_procedures)];
>>> diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
>>> index 82d8fb422092..c1eeef52545c 100644
>>> --- a/include/linux/nfs4.h
>>> +++ b/include/linux/nfs4.h
>>> @@ -540,8 +540,8 @@ enum {
>>>
>>> NFSPROC4_CLNT_LOOKUPP,
>>> NFSPROC4_CLNT_LAYOUTERROR,
>>> -
>>> NFSPROC4_CLNT_COPY_NOTIFY,
>>> + NFSPROC4_CLNT_READ_PLUS,
>>> };
>>>
>>> /* nfs41 types */
>>> diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
>>> index 465fa98258a3..11248c5a7b24 100644
>>> --- a/include/linux/nfs_fs_sb.h
>>> +++ b/include/linux/nfs_fs_sb.h
>>> @@ -281,5 +281,6 @@ struct nfs_server {
>>> #define NFS_CAP_OFFLOAD_CANCEL (1U << 25)
>>> #define NFS_CAP_LAYOUTERROR (1U << 26)
>>> #define NFS_CAP_COPY_NOTIFY (1U << 27)
>>> +#define NFS_CAP_READ_PLUS (1U << 28)
>>>
>>> #endif
>>> diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
>>> index 94c77ed55ce1..8efbf3d8b263 100644
>>> --- a/include/linux/nfs_xdr.h
>>> +++ b/include/linux/nfs_xdr.h
>>> @@ -655,7 +655,7 @@ struct nfs_pgio_args {
>>> struct nfs_pgio_res {
>>> struct nfs4_sequence_res seq_res;
>>> struct nfs_fattr * fattr;
>>> - __u32 count;
>>> + __u64 count;
>>> __u32 op_status;
>>> union {
>>> struct {
>>> --
>>> 2.25.0
>>>
>>
>> --
>> Chuck Lever
--
Chuck Lever
^ permalink raw reply
* [MODERATED] Re: [PATCH 0/2] more sampling fun 0
From: Andi Kleen @ 2020-02-20 14:55 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220081420.GA3328448@kroah.com>
> Then we need to stop using RDRAND internally for our "give me a random
> number api" which has spread to more and more parts of the kernel.
Only if that API is called frequently enough. AFAIK it is not.
Normally it's used for rare rekeying of hash tables etc., which
doesn't happen very often.
> Here's a patch that does so:
> https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/
> which I'm going to advise get merged now and backported to the stable
> branches.
Don't see any reason at this point. Only do it if there's an actual
indication of a problem.
-Andi
^ permalink raw reply
* [PATCH net 2/3] s390/qeth: don't warn for napi with 0 budget
From: Julian Wiedmann @ 2020-02-20 14:54 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Heiko Carstens, Ursula Braun, Julian Wiedmann
In-Reply-To: <20200220145456.11571-1-jwi@linux.ibm.com>
Calling napi->poll() with 0 budget is a legitimate use by netpoll.
Fixes: a1c3ed4c9ca0 ("qeth: NAPI support for l2 and l3 discipline")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
---
drivers/s390/net/qeth_core_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index 9639938581f5..2264c6619def 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -5447,7 +5447,6 @@ static int qeth_extract_skbs(struct qeth_card *card, int budget,
{
int work_done = 0;
- WARN_ON_ONCE(!budget);
*done = false;
while (budget) {
--
2.17.1
^ permalink raw reply related
* [PATCH net 1/3] s390/qeth: vnicc Fix EOPNOTSUPP precedence
From: Julian Wiedmann @ 2020-02-20 14:54 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Heiko Carstens, Ursula Braun,
Alexandra Winter, Julian Wiedmann
In-Reply-To: <20200220145456.11571-1-jwi@linux.ibm.com>
From: Alexandra Winter <wintera@linux.ibm.com>
When getting or setting VNICC parameters, the error code EOPNOTSUPP
should have precedence over EBUSY.
EBUSY is used because vnicc feature and bridgeport feature are mutually
exclusive, which is a temporary condition.
Whereas EOPNOTSUPP indicates that the HW does not support all or parts of
the vnicc feature.
This issue causes the vnicc sysfs params to show 'blocked by bridgeport'
for HW that does not support VNICC at all.
Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
---
drivers/s390/net/qeth_l2_main.c | 29 +++++++++++++----------------
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/s390/net/qeth_l2_main.c b/drivers/s390/net/qeth_l2_main.c
index 692bd2623401..9972d96820f3 100644
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -1707,15 +1707,14 @@ int qeth_l2_vnicc_set_state(struct qeth_card *card, u32 vnicc, bool state)
QETH_CARD_TEXT(card, 2, "vniccsch");
- /* do not change anything if BridgePort is enabled */
- if (qeth_bridgeport_is_in_use(card))
- return -EBUSY;
-
/* check if characteristic and enable/disable are supported */
if (!(card->options.vnicc.sup_chars & vnicc) ||
!(card->options.vnicc.set_char_sup & vnicc))
return -EOPNOTSUPP;
+ if (qeth_bridgeport_is_in_use(card))
+ return -EBUSY;
+
/* set enable/disable command and store wanted characteristic */
if (state) {
cmd = IPA_VNICC_ENABLE;
@@ -1761,14 +1760,13 @@ int qeth_l2_vnicc_get_state(struct qeth_card *card, u32 vnicc, bool *state)
QETH_CARD_TEXT(card, 2, "vniccgch");
- /* do not get anything if BridgePort is enabled */
- if (qeth_bridgeport_is_in_use(card))
- return -EBUSY;
-
/* check if characteristic is supported */
if (!(card->options.vnicc.sup_chars & vnicc))
return -EOPNOTSUPP;
+ if (qeth_bridgeport_is_in_use(card))
+ return -EBUSY;
+
/* if card is ready, query current VNICC state */
if (qeth_card_hw_is_reachable(card))
rc = qeth_l2_vnicc_query_chars(card);
@@ -1786,15 +1784,14 @@ int qeth_l2_vnicc_set_timeout(struct qeth_card *card, u32 timeout)
QETH_CARD_TEXT(card, 2, "vniccsto");
- /* do not change anything if BridgePort is enabled */
- if (qeth_bridgeport_is_in_use(card))
- return -EBUSY;
-
/* check if characteristic and set_timeout are supported */
if (!(card->options.vnicc.sup_chars & QETH_VNICC_LEARNING) ||
!(card->options.vnicc.getset_timeout_sup & QETH_VNICC_LEARNING))
return -EOPNOTSUPP;
+ if (qeth_bridgeport_is_in_use(card))
+ return -EBUSY;
+
/* do we need to do anything? */
if (card->options.vnicc.learning_timeout == timeout)
return rc;
@@ -1823,14 +1820,14 @@ int qeth_l2_vnicc_get_timeout(struct qeth_card *card, u32 *timeout)
QETH_CARD_TEXT(card, 2, "vniccgto");
- /* do not get anything if BridgePort is enabled */
- if (qeth_bridgeport_is_in_use(card))
- return -EBUSY;
-
/* check if characteristic and get_timeout are supported */
if (!(card->options.vnicc.sup_chars & QETH_VNICC_LEARNING) ||
!(card->options.vnicc.getset_timeout_sup & QETH_VNICC_LEARNING))
return -EOPNOTSUPP;
+
+ if (qeth_bridgeport_is_in_use(card))
+ return -EBUSY;
+
/* if card is ready, get timeout. Otherwise, just return stored value */
*timeout = card->options.vnicc.learning_timeout;
if (qeth_card_hw_is_reachable(card))
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] backlight: add led-backlight driver
From: Tony Lindgren @ 2020-02-20 14:54 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Pavel Machek, Lee Jones, kernel list, linux-arm-kernel,
linux-omap, nekit1000, mpartap, merlijn, martin_rysavy, agx,
daniel.thompson, jingoohan1, dri-devel, tomi.valkeinen, jjhiblot
In-Reply-To: <20200219234437.l6ac7usebu7rnzsy@earth.universe>
* Sebastian Reichel <sre@kernel.org> [200219 23:45]:
> Finally :)
>
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Yeah thanks for your persistent effort on getting this working :)
Regards,
Tony
^ permalink raw reply
* [PATCH net 3/3] s390/qeth: fix off-by-one in RX copybreak check
From: Julian Wiedmann @ 2020-02-20 14:54 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Heiko Carstens, Ursula Braun, Julian Wiedmann
In-Reply-To: <20200220145456.11571-1-jwi@linux.ibm.com>
The RX copybreak is intended as the _max_ value where the frame's data
should be copied. So for frame_len == copybreak, don't build an SG skb.
Fixes: 4a71df50047f ("qeth: new qeth device driver")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
---
drivers/s390/net/qeth_core_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index 2264c6619def..5efcaa43615b 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -5344,7 +5344,7 @@ static int qeth_extract_skb(struct qeth_card *card,
}
use_rx_sg = (card->options.cq == QETH_CQ_ENABLED) ||
- ((skb_len >= card->options.rx_sg_cb) &&
+ (skb_len > card->options.rx_sg_cb &&
!atomic_read(&card->force_alloc_skb) &&
!IS_OSN(card));
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 01/19] vfs: syscall: Add fsinfo() to query filesystem information [ver #16]
From: Jann Horn @ 2020-02-20 14:54 UTC (permalink / raw)
To: David Howells
Cc: Al Viro, raven, Miklos Szeredi, Christian Brauner, Linux API,
linux-fsdevel, kernel list
In-Reply-To: <584179.1582196636@warthog.procyon.org.uk>
On Thu, Feb 20, 2020 at 12:04 PM David Howells <dhowells@redhat.com> wrote:
> Jann Horn <jannh@google.com> wrote:
>
> > > +int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> > ...
> > Please add a check here to ensure that "ret" actually fits into the
> > buffer (and use WARN_ON() if you think the check should never fire).
> > Otherwise I think this is too fragile.
>
> How about:
>
> int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> {
> unsigned int len;
> char *p = ctx->buffer;
> int ret = 0;
> if (s) {
> len = strlen(s);
> if (len > ctx->buf_size - 1)
> len = ctx->buf_size;
> if (!ctx->want_size_only) {
> memcpy(p, s, len);
> p[len] = 0;
I think this is off-by-one? If len was too big, it is set to
ctx->buf_size, so in that case this effectively becomes
`ctx->buffer[ctx->buf_size] = 0`, which is one byte out of bounds,
right?
Maybe use something like `len = min_t(size_t, strlen(s), ctx->buf_size-1)` ?
Looks good apart from that, I think.
> }
> ret = len;
> }
> return ret;
> }
[...]
> > > + return ctx->usage;
> >
> > It is kind of weird that you have to return the ctx->usage everywhere
> > even though the caller already has ctx...
>
> At this point, it's only used and returned by fsinfo_attributes() and really
> is only for the use of the attribute getter function.
>
> I could, I suppose, return the amount of data in ctx->usage and then preset it
> for VSTRUCT-type objects. Unfortunately, I can't make the getter return void
> since it might have to return an error.
Yeah, then you'd be passing around the error separately from the
length... I don't know whether that'd make things better or worse.
[...]
> > > +struct fsinfo_attribute {
> > > + unsigned int attr_id; /* The ID of the attribute */
> > > + enum fsinfo_value_type type:8; /* The type of the attribute's value(s) */
> > > + unsigned int flags:8;
> > > + unsigned int size:16; /* - Value size (FSINFO_STRUCT) */
> > > + unsigned int element_size:16; /* - Element size (FSINFO_LIST) */
> > > + int (*get)(struct path *path, struct fsinfo_context *params);
> > > +};
> >
> > Why the bitfields? It doesn't look like that's going to help you much,
> > you'll just end up with 6 bytes of holes on x86-64:
>
> Expanding them to non-bitfields will require an extra 10 bytes, making the
> struct 8 bytes bigger with 4 bytes of padding. I can do that if you'd rather.
Wouldn't this still have the same total size?
struct fsinfo_attribute {
unsigned int attr_id; /* 0x0-0x3 */
enum fsinfo_value_type type; /* 0x4-0x7 */
u8 flags; /* 0x8-0x8 */
/* 1-byte hole */
u16 size; /* 0xa-0xb */
u16 element_size; /* 0xc-0xd */
/* 2-byte hole */
int (*get)(...); /* 0x10-0x18 */
};
But it's not like I really care about this detail all that much, feel
free to leave it as-is.
^ permalink raw reply
* Su factura eletrónica.
From: 412684 LinuxMercedes @ 2020-02-20 14:54 UTC (permalink / raw)
To: linux-nvdimm
Estimado
cliente, linux-nvdimm@lists.01.org
Se
adjunta su factura electrónica para el mes de febrero.
Factura
20.02.2020(652KB).PDF
Saludos
Cordiales!
No respondas a este correo
electrónico.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply
* [PATCH net 0/3] s390/qeth: fixes 2020-02-20
From: Julian Wiedmann @ 2020-02-20 14:54 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Heiko Carstens, Ursula Braun, Julian Wiedmann
Hi Dave,
please apply the following patch series for qeth to netdev's net tree.
This corrects three minor issues:
1) return a more fitting errno when VNICC cmds are not supported,
2) remove a bogus WARN in the NAPI code, and
3) be _very_ pedantic about the RX copybreak.
Thanks,
Julian
Alexandra Winter (1):
s390/qeth: vnicc Fix EOPNOTSUPP precedence
Julian Wiedmann (2):
s390/qeth: don't warn for napi with 0 budget
s390/qeth: fix off-by-one in RX copybreak check
drivers/s390/net/qeth_core_main.c | 3 +--
drivers/s390/net/qeth_l2_main.c | 29 +++++++++++++----------------
2 files changed, 14 insertions(+), 18 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [RFC PATCH v3 03/27] qcow2: Process QCOW2_CLUSTER_ZERO_ALLOC clusters in handle_copied()
From: Eric Blake @ 2020-02-20 14:53 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <e327f4c1ed2f9626ce018c1fd2b9db437721b30c.1577014346.git.berto@igalia.com>
On 12/22/19 5:36 AM, Alberto Garcia wrote:
> When writing to a qcow2 file there are two functions that take a
> virtual offset and return a host offset, possibly allocating new
> clusters if necessary:
>
> - handle_copied() looks for normal data clusters that are already
> allocated and have a reference count of 1. In those clusters we
> can simply write the data and there is no need to perform any
> copy-on-write.
>
> - handle_alloc() looks for clusters that do need copy-on-write,
> either because they haven't been allocated yet, because their
> reference count is != 1 or because they are ZERO_ALLOC clusters.
>
> The ZERO_ALLOC case is a bit special because those are clusters that
> are already allocated and they could perfectly be dealt with in
> handle_copied() (as long as copy-on-write is performed when required).
>
> In fact, there is extra code specifically for them in handle_alloc()
> that tries to reuse the existing allocation if possible and frees them
> otherwise.
>
> This patch changes the handling of ZERO_ALLOC clusters so the
> semantics of these two functions are now like this:
>
> - handle_copied() looks for clusters that are already allocated and
> which we can overwrite (NORMAL and ZERO_ALLOC clusters with a
> reference count of 1).
>
> - handle_alloc() looks for clusters for which we need a new
> allocation (all other cases).
>
> One importante difference after this change is that clusters found in
important
> handle_copied() may now require copy-on-write, but this will be anyway
> necessary once we add support for subclusters.
necessary anyway
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> block/qcow2-cluster.c | 226 +++++++++++++++++++++++-------------------
> 1 file changed, 126 insertions(+), 100 deletions(-)
A bit of an increase in code size, but I think it does reduce the
overall complexity to treat ZERO_ALLOC like normal. The patch is big,
but I don't see any sane way to split it. Overall, I like it.
>
> diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
> index e078bddcc2..9387f15866 100644
> --- a/block/qcow2-cluster.c
> +++ b/block/qcow2-cluster.c
> @@ -1069,18 +1112,20 @@ static void calculate_l2_meta(BlockDriverState *bs,
> QLIST_INSERT_HEAD(&s->cluster_allocs, *m, next_in_flight);
> }
>
> -/* Returns true if writing to a cluster requires COW */
> -static bool cluster_needs_cow(BlockDriverState *bs, uint64_t l2_entry)
> +/* Returns true if writing to the cluster pointed to by @l2_entry
> + * requires a new allocation (that is, if the cluster is unallocated
> + * or has refcount > 1 and therefore cannot be written in-place). */
syntax check wants you to wing this comment, now.
> +static bool cluster_needs_new_alloc(BlockDriverState *bs, uint64_t l2_entry)
The rename makes sense.
> @@ -1337,9 +1400,10 @@ static int do_alloc_cluster_offset(BlockDriverState *bs, uint64_t guest_offset,
> }
>
> /*
> - * Allocates new clusters for an area that either is yet unallocated or needs a
> - * copy on write. If *host_offset is not INV_OFFSET, clusters are only
> - * allocated if the new allocation can match the specified host offset.
> + * Allocates new clusters for an area that either is yet unallocated or
> + * cannot be overwritten in-place. If *host_offset is not INV_OFFSET,
s/either is yet/is either still/
> + * clusters are only allocated if the new allocation can match the specified
> + * host offset.
> *
> * Note that guest_offset may not be cluster aligned. In this case, the
> * returned *host_offset points to exact byte referenced by guest_offset and
Findings are minor and you can fix them up when dropping RFC.
Reviewed-by: Eric Blake <eblake@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* [PATCH v6 03/16] mm: Introduce fault_signal_pending()
From: Peter Xu @ 2020-02-20 14:54 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Martin Cracauer, Mike Rapoport, Hugh Dickins, Jerome Glisse,
peterx, Kirill A . Shutemov, Matthew Wilcox, Pavel Emelyanov,
Brian Geffon, Maya Gokhale, Denis Plotnikov, Andrea Arcangeli,
Johannes Weiner, Dr . David Alan Gilbert, Linus Torvalds,
Mike Kravetz, Marty McFadden, David Hildenbrand, Bobby Powers,
Mel Gorman
In-Reply-To: <20200220145432.4561-1-peterx@redhat.com>
For most architectures, we've got a quick path to detect fatal signal
after a handle_mm_fault(). Introduce a helper for that quick path.
It cleans the current codes a bit so we don't need to duplicate the
same check across archs. More importantly, this will be an unified
place that we handle the signal immediately right after an interrupted
page fault, so it'll be much easier for us if we want to change the
behavior of handling signals later on for all the archs.
Note that currently only part of the archs are using this new helper,
because some archs have their own way to handle signals. In the
follow up patches, we'll try to apply this helper to all the rest of
archs.
Another note is that the "regs" parameter in the new helper is not
used yet. It'll be used very soon. Now we kept it in this patch only
to avoid touching all the archs again in the follow up patches.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
arch/alpha/mm/fault.c | 2 +-
arch/arm/mm/fault.c | 2 +-
arch/hexagon/mm/vm_fault.c | 2 +-
arch/ia64/mm/fault.c | 2 +-
arch/m68k/mm/fault.c | 2 +-
arch/microblaze/mm/fault.c | 2 +-
arch/mips/mm/fault.c | 2 +-
arch/nds32/mm/fault.c | 2 +-
arch/nios2/mm/fault.c | 2 +-
arch/openrisc/mm/fault.c | 2 +-
arch/parisc/mm/fault.c | 2 +-
arch/riscv/mm/fault.c | 2 +-
arch/s390/mm/fault.c | 3 +--
arch/sparc/mm/fault_32.c | 2 +-
arch/sparc/mm/fault_64.c | 2 +-
arch/unicore32/mm/fault.c | 2 +-
arch/xtensa/mm/fault.c | 2 +-
include/linux/sched/signal.h | 13 +++++++++++++
18 files changed, 30 insertions(+), 18 deletions(-)
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index 741e61ef9d3f..aea33b599037 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -150,7 +150,7 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
the fault. */
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index bd0f4821f7e1..937b81ff8649 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -295,7 +295,7 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
* signal first. We do not need to release the mmap_sem because
* it would already be released in __lock_page_or_retry in
* mm/filemap.c. */
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+ if (fault_signal_pending(fault, regs)) {
if (!user_mode(regs))
goto no_context;
return 0;
diff --git a/arch/hexagon/mm/vm_fault.c b/arch/hexagon/mm/vm_fault.c
index b3bc71680ae4..d19beaf11b4c 100644
--- a/arch/hexagon/mm/vm_fault.c
+++ b/arch/hexagon/mm/vm_fault.c
@@ -91,7 +91,7 @@ void do_page_fault(unsigned long address, long cause, struct pt_regs *regs)
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return;
/* The most common case -- we are done. */
diff --git a/arch/ia64/mm/fault.c b/arch/ia64/mm/fault.c
index c2f299fe9e04..211b4f439384 100644
--- a/arch/ia64/mm/fault.c
+++ b/arch/ia64/mm/fault.c
@@ -141,7 +141,7 @@ ia64_do_page_fault (unsigned long address, unsigned long isr, struct pt_regs *re
*/
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/m68k/mm/fault.c b/arch/m68k/mm/fault.c
index e9b1d7585b43..a455e202691b 100644
--- a/arch/m68k/mm/fault.c
+++ b/arch/m68k/mm/fault.c
@@ -138,7 +138,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long address,
fault = handle_mm_fault(vma, address, flags);
pr_debug("handle_mm_fault returns %x\n", fault);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return 0;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/microblaze/mm/fault.c b/arch/microblaze/mm/fault.c
index e6a810b0c7ad..cdde01dcdfc3 100644
--- a/arch/microblaze/mm/fault.c
+++ b/arch/microblaze/mm/fault.c
@@ -217,7 +217,7 @@ void do_page_fault(struct pt_regs *regs, unsigned long address,
*/
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index 1e8d00793784..0ee6fafc57bc 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -154,7 +154,7 @@ static void __kprobes __do_page_fault(struct pt_regs *regs, unsigned long write,
*/
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(regs))
return;
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
diff --git a/arch/nds32/mm/fault.c b/arch/nds32/mm/fault.c
index 906dfb25353c..0e63f81eff5b 100644
--- a/arch/nds32/mm/fault.c
+++ b/arch/nds32/mm/fault.c
@@ -214,7 +214,7 @@ void do_page_fault(unsigned long entry, unsigned long addr,
* signal first. We do not need to release the mmap_sem because it
* would already be released in __lock_page_or_retry in mm/filemap.c.
*/
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+ if (fault_signal_pending(fault, regs)) {
if (!user_mode(regs))
goto no_context;
return;
diff --git a/arch/nios2/mm/fault.c b/arch/nios2/mm/fault.c
index 6a2e716b959f..704ace8ca0ee 100644
--- a/arch/nios2/mm/fault.c
+++ b/arch/nios2/mm/fault.c
@@ -133,7 +133,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs, unsigned long cause,
*/
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/openrisc/mm/fault.c b/arch/openrisc/mm/fault.c
index 5d4d3a9691d0..85c7eb0c0186 100644
--- a/arch/openrisc/mm/fault.c
+++ b/arch/openrisc/mm/fault.c
@@ -161,7 +161,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs, unsigned long address,
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index adbd5e2144a3..f9be1d1cb43f 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -304,7 +304,7 @@ void do_page_fault(struct pt_regs *regs, unsigned long code,
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index cf7248e07f43..1d3869e9ddef 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -117,7 +117,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
* signal first. We do not need to release the mmap_sem because it
* would already be released in __lock_page_or_retry in mm/filemap.c.
*/
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(tsk))
+ if (fault_signal_pending(fault, regs))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index 7b0bb475c166..179cf92a56e5 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -480,8 +480,7 @@ static inline vm_fault_t do_exception(struct pt_regs *regs, int access)
* the fault.
*/
fault = handle_mm_fault(vma, address, flags);
- /* No reason to continue if interrupted by SIGKILL. */
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+ if (fault_signal_pending(fault, regs)) {
fault = VM_FAULT_SIGNAL;
if (flags & FAULT_FLAG_RETRY_NOWAIT)
goto out_up;
diff --git a/arch/sparc/mm/fault_32.c b/arch/sparc/mm/fault_32.c
index 89976c9b936c..6efbeb227644 100644
--- a/arch/sparc/mm/fault_32.c
+++ b/arch/sparc/mm/fault_32.c
@@ -237,7 +237,7 @@ asmlinkage void do_sparc_fault(struct pt_regs *regs, int text_fault, int write,
*/
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/sparc/mm/fault_64.c b/arch/sparc/mm/fault_64.c
index 8b7ddbd14b65..dd1ed6555831 100644
--- a/arch/sparc/mm/fault_64.c
+++ b/arch/sparc/mm/fault_64.c
@@ -425,7 +425,7 @@ asmlinkage void __kprobes do_sparc64_fault(struct pt_regs *regs)
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
goto exit_exception;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/unicore32/mm/fault.c b/arch/unicore32/mm/fault.c
index 76342de9cf8c..59d0e6ec2cfc 100644
--- a/arch/unicore32/mm/fault.c
+++ b/arch/unicore32/mm/fault.c
@@ -250,7 +250,7 @@ static int do_pf(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
* signal first. We do not need to release the mmap_sem because
* it would already be released in __lock_page_or_retry in
* mm/filemap.c. */
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return 0;
if (!(fault & VM_FAULT_ERROR) && (flags & FAULT_FLAG_ALLOW_RETRY)) {
diff --git a/arch/xtensa/mm/fault.c b/arch/xtensa/mm/fault.c
index bee30a77cd70..59515905d4ad 100644
--- a/arch/xtensa/mm/fault.c
+++ b/arch/xtensa/mm/fault.c
@@ -110,7 +110,7 @@ void do_page_fault(struct pt_regs *regs)
*/
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if (fault_signal_pending(fault, regs))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
index 88050259c466..4c87ffce64d1 100644
--- a/include/linux/sched/signal.h
+++ b/include/linux/sched/signal.h
@@ -369,6 +369,19 @@ static inline int signal_pending_state(long state, struct task_struct *p)
return (state & TASK_INTERRUPTIBLE) || __fatal_signal_pending(p);
}
+/*
+ * This should only be used in fault handlers to decide whether we
+ * should stop the current fault routine to handle the signals
+ * instead, especially with the case where we've got interrupted with
+ * a VM_FAULT_RETRY.
+ */
+static inline bool fault_signal_pending(unsigned int fault_flags,
+ struct pt_regs *regs)
+{
+ return unlikely((fault_flags & VM_FAULT_RETRY) &&
+ fatal_signal_pending(current));
+}
+
/*
* Reevaluate whether the task has signals pending delivery.
* Wake the task if so.
--
2.24.1
^ permalink raw reply related
* [PATCH v6 00/16] mm: Page fault enhancements
From: Peter Xu @ 2020-02-20 14:54 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Martin Cracauer, Mike Rapoport, Hugh Dickins, Jerome Glisse,
peterx, Kirill A . Shutemov, Matthew Wilcox, Pavel Emelyanov,
Brian Geffon, Maya Gokhale, Denis Plotnikov, Andrea Arcangeli,
Johannes Weiner, Dr . David Alan Gilbert, Linus Torvalds,
Mike Kravetz, Marty McFadden, David Hildenbrand, Bobby Powers,
Mel Gorman
This is v6 of the series. It is majorly a rebase to 5.6-rc2, nothing
else to be expected (plus some tests after the rebase). Instead of
rewrite the cover letter I decided to use what we have for v5.
Adding extra CCs for both Bobby Powers <bobbypowers@gmail.com> and
Brian Geffon <bgeffon@google.com>.
Any review comment is appreciated. Thanks,
=============== v5 cover letter ==================
This is v5 of the series. As Matthew suggested, I split the previous
patch "mm: Return faster for non-fatal signals in user mode faults"
into a few smaller ones:
1. One patch to introduce fatal_signal_pending(), and use it in
archs that can directly apply
2. A few more patches to let the rest archs to use the new helper.
With that we can have an unified entry for signal detection
3. One last patch to change fatal_signal_pending() to detect
userspace non-fatal signal
Nothing should have changed in the rest patches. Because the fault
retry patches will depend on the previous ones, I decided to simply
repost all the patches.
Here's the new patchset layout:
Patch 1-2: cleanup, and potential bugfix of hugetlbfs on fault retry
Patch 3-9: let page fault to respond to non-fatal signals faster
Patch 10: remove the userfaultfd NOPAGE emulation
Patch 11-14: allow page fault to retry more than once
Patch 15-16: let gup code to use FAULT_FLAG_KILLABLE too
I would really appreciate any review comments for the series,
especially for the first two patches which IMHO are even not related
to this patchset and they should either cleanup or fix things.
Smoke tested on x86 only.
Thanks,
v5:
- split "mm: Return faster for non-fatal signals in user mode faults"
into a few more patches, let all archs to use an unified entry for
fast signal handling (fatal_signal_pending)
v4:
- use lore.kernel.org for all the links in commit messages [Kirill]
- one more patch ("mm/gup: Fix __get_user_pages() on fault retry of
hugetlb") to fix hugetlb path on fault retry
- one more patch ("mm/gup: Allow to react to fatal signals") to:
- use down_read_killable() properly [Linus]
- pass in FAULT_FLAG_KILLABLE for all GUP [Linus]
- one more patch ("mm/userfaultfd: Honor FAULT_FLAG_KILLABLE in fault
path") to let handle_userfaultfd() respect FAULT_FLAG_KILLABLE.
Should have no functional change after previous two new patches.
v3:
- check fatal signals in __get_user_page_locked() [Linus]
- add r-bs
v2:
- resent previous version, rebase only
=============== v1 cover letter ==================
This series is split out of userfaultfd-wp series to only cover the
general page fault changes, since it seems to make sense itself.
Basically it does two things:
(a) Allows the page fault handlers to be more interactive on not
only SIGKILL, but also the rest of userspace signals (especially
for user-mode faults), and,
(b) Allows the page fault retry (VM_FAULT_RETRY) to happen for more
than once.
I'm keeping the CC list as in uffd-wp v5, hopefully I'm not sending
too much spams...
And, instead of writting again the cover letter, I'm just copy-pasting
my previous link here which has more details on why we do this:
https://patchwork.kernel.org/cover/10691991/
The major change from that latest version should be that we introduced
a new page fault flag FAULT_FLAG_INTERRUPTIBLE as suggested by Linus
[1] to represents that we would like the fault handler to respond to
non-fatal signals. Also, we're more careful now on when to do the
immediate return of the page fault for such signals. For example, now
we'll only check against signal_pending() for user-mode page faults
and we keep the kernel-mode page fault patch untouched for it. More
information can be found in separate patches.
The patchset is only lightly tested on x86.
All comments are greatly welcomed. Thanks,
[1] https://lkml.org/lkml/2019/6/25/1382
Peter Xu (16):
mm/gup: Rename "nonblocking" to "locked" where proper
mm/gup: Fix __get_user_pages() on fault retry of hugetlb
mm: Introduce fault_signal_pending()
x86/mm: Use helper fault_signal_pending()
arc/mm: Use helper fault_signal_pending()
arm64/mm: Use helper fault_signal_pending()
powerpc/mm: Use helper fault_signal_pending()
sh/mm: Use helper fault_signal_pending()
mm: Return faster for non-fatal signals in user mode faults
userfaultfd: Don't retake mmap_sem to emulate NOPAGE
mm: Introduce FAULT_FLAG_DEFAULT
mm: Introduce FAULT_FLAG_INTERRUPTIBLE
mm: Allow VM_FAULT_RETRY for multiple times
mm/gup: Allow VM_FAULT_RETRY for multiple times
mm/gup: Allow to react to fatal signals
mm/userfaultfd: Honor FAULT_FLAG_KILLABLE in fault path
arch/alpha/mm/fault.c | 6 +--
arch/arc/mm/fault.c | 35 +++++--------
arch/arm/mm/fault.c | 7 +--
arch/arm64/mm/fault.c | 26 +++------
arch/hexagon/mm/vm_fault.c | 5 +-
arch/ia64/mm/fault.c | 5 +-
arch/m68k/mm/fault.c | 7 +--
arch/microblaze/mm/fault.c | 5 +-
arch/mips/mm/fault.c | 5 +-
arch/nds32/mm/fault.c | 5 +-
arch/nios2/mm/fault.c | 7 +--
arch/openrisc/mm/fault.c | 5 +-
arch/parisc/mm/fault.c | 8 ++-
arch/powerpc/mm/fault.c | 20 ++-----
arch/riscv/mm/fault.c | 9 +---
arch/s390/mm/fault.c | 10 ++--
arch/sh/mm/fault.c | 13 +++--
arch/sparc/mm/fault_32.c | 5 +-
arch/sparc/mm/fault_64.c | 5 +-
arch/um/kernel/trap.c | 3 +-
arch/unicore32/mm/fault.c | 8 ++-
arch/x86/mm/fault.c | 30 +++++------
arch/xtensa/mm/fault.c | 5 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 12 +++--
fs/userfaultfd.c | 62 ++++++++++------------
include/linux/mm.h | 81 ++++++++++++++++++++++++----
include/linux/sched/signal.h | 14 +++++
mm/filemap.c | 2 +-
mm/gup.c | 93 +++++++++++++++++++++------------
mm/hugetlb.c | 17 +++---
mm/internal.h | 6 +--
31 files changed, 281 insertions(+), 240 deletions(-)
--
2.24.1
^ permalink raw reply
* [PATCH v6 02/16] mm/gup: Fix __get_user_pages() on fault retry of hugetlb
From: Peter Xu @ 2020-02-20 14:54 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Martin Cracauer, Mike Rapoport, Hugh Dickins, Jerome Glisse,
peterx, Kirill A . Shutemov, Matthew Wilcox, Pavel Emelyanov,
Brian Geffon, Maya Gokhale, Denis Plotnikov, Andrea Arcangeli,
Johannes Weiner, Dr . David Alan Gilbert, Linus Torvalds,
Mike Kravetz, Marty McFadden, David Hildenbrand, Bobby Powers,
Mel Gorman
In-Reply-To: <20200220145432.4561-1-peterx@redhat.com>
When follow_hugetlb_page() returns with *locked==0, it means we've got
a VM_FAULT_RETRY within the fauling process and we've released the
mmap_sem. When that happens, we should stop and bail out.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
mm/gup.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index 1b4411bd0042..76cb420c0fb7 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -849,6 +849,16 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
i = follow_hugetlb_page(mm, vma, pages, vmas,
&start, &nr_pages, i,
gup_flags, locked);
+ if (locked && *locked == 0) {
+ /*
+ * We've got a VM_FAULT_RETRY
+ * and we've lost mmap_sem.
+ * We must stop here.
+ */
+ BUG_ON(gup_flags & FOLL_NOWAIT);
+ BUG_ON(ret != 0);
+ goto out;
+ }
continue;
}
}
--
2.24.1
^ permalink raw reply related
* [PATCH v6 01/16] mm/gup: Rename "nonblocking" to "locked" where proper
From: Peter Xu @ 2020-02-20 14:54 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Martin Cracauer, Mike Rapoport, Hugh Dickins, Jerome Glisse,
peterx, Kirill A . Shutemov, Matthew Wilcox, Pavel Emelyanov,
Brian Geffon, Maya Gokhale, Denis Plotnikov, Andrea Arcangeli,
Johannes Weiner, Dr . David Alan Gilbert, Linus Torvalds,
Mike Kravetz, Marty McFadden, David Hildenbrand, Bobby Powers,
Mel Gorman
In-Reply-To: <20200220145432.4561-1-peterx@redhat.com>
There's plenty of places around __get_user_pages() that has a parameter
"nonblocking" which does not really mean that "it won't block" (because
it can really block) but instead it shows whether the mmap_sem is
released by up_read() during the page fault handling mostly when
VM_FAULT_RETRY is returned.
We have the correct naming in e.g. get_user_pages_locked() or
get_user_pages_remote() as "locked", however there're still many places
that are using the "nonblocking" as name.
Renaming the places to "locked" where proper to better suite the
functionality of the variable. While at it, fixing up some of the
comments accordingly.
Reviewed-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
---
mm/gup.c | 44 +++++++++++++++++++++-----------------------
mm/hugetlb.c | 8 ++++----
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 1b521e0ac1de..1b4411bd0042 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -630,12 +630,12 @@ static int get_gate_page(struct mm_struct *mm, unsigned long address,
}
/*
- * mmap_sem must be held on entry. If @nonblocking != NULL and
- * *@flags does not include FOLL_NOWAIT, the mmap_sem may be released.
- * If it is, *@nonblocking will be set to 0 and -EBUSY returned.
+ * mmap_sem must be held on entry. If @locked != NULL and *@flags
+ * does not include FOLL_NOWAIT, the mmap_sem may be released. If it
+ * is, *@locked will be set to 0 and -EBUSY returned.
*/
static int faultin_page(struct task_struct *tsk, struct vm_area_struct *vma,
- unsigned long address, unsigned int *flags, int *nonblocking)
+ unsigned long address, unsigned int *flags, int *locked)
{
unsigned int fault_flags = 0;
vm_fault_t ret;
@@ -647,7 +647,7 @@ static int faultin_page(struct task_struct *tsk, struct vm_area_struct *vma,
fault_flags |= FAULT_FLAG_WRITE;
if (*flags & FOLL_REMOTE)
fault_flags |= FAULT_FLAG_REMOTE;
- if (nonblocking)
+ if (locked)
fault_flags |= FAULT_FLAG_ALLOW_RETRY;
if (*flags & FOLL_NOWAIT)
fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_RETRY_NOWAIT;
@@ -673,8 +673,8 @@ static int faultin_page(struct task_struct *tsk, struct vm_area_struct *vma,
}
if (ret & VM_FAULT_RETRY) {
- if (nonblocking && !(fault_flags & FAULT_FLAG_RETRY_NOWAIT))
- *nonblocking = 0;
+ if (locked && !(fault_flags & FAULT_FLAG_RETRY_NOWAIT))
+ *locked = 0;
return -EBUSY;
}
@@ -751,7 +751,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
* only intends to ensure the pages are faulted in.
* @vmas: array of pointers to vmas corresponding to each page.
* Or NULL if the caller does not require them.
- * @nonblocking: whether waiting for disk IO or mmap_sem contention
+ * @locked: whether we're still with the mmap_sem held
*
* Returns either number of pages pinned (which may be less than the
* number requested), or an error. Details about the return value:
@@ -786,13 +786,11 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
* appropriate) must be called after the page is finished with, and
* before put_page is called.
*
- * If @nonblocking != NULL, __get_user_pages will not wait for disk IO
- * or mmap_sem contention, and if waiting is needed to pin all pages,
- * *@nonblocking will be set to 0. Further, if @gup_flags does not
- * include FOLL_NOWAIT, the mmap_sem will be released via up_read() in
- * this case.
+ * If @locked != NULL, *@locked will be set to 0 when mmap_sem is
+ * released by an up_read(). That can happen if @gup_flags does not
+ * have FOLL_NOWAIT.
*
- * A caller using such a combination of @nonblocking and @gup_flags
+ * A caller using such a combination of @locked and @gup_flags
* must therefore hold the mmap_sem for reading only, and recognize
* when it's been released. Otherwise, it must be held for either
* reading or writing and will not be released.
@@ -804,7 +802,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
- struct vm_area_struct **vmas, int *nonblocking)
+ struct vm_area_struct **vmas, int *locked)
{
long ret = 0, i = 0;
struct vm_area_struct *vma = NULL;
@@ -850,7 +848,7 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
if (is_vm_hugetlb_page(vma)) {
i = follow_hugetlb_page(mm, vma, pages, vmas,
&start, &nr_pages, i,
- gup_flags, nonblocking);
+ gup_flags, locked);
continue;
}
}
@@ -868,7 +866,7 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
page = follow_page_mask(vma, start, foll_flags, &ctx);
if (!page) {
ret = faultin_page(tsk, vma, start, &foll_flags,
- nonblocking);
+ locked);
switch (ret) {
case 0:
goto retry;
@@ -1129,7 +1127,7 @@ static __always_inline long __get_user_pages_locked(struct task_struct *tsk,
* @vma: target vma
* @start: start address
* @end: end address
- * @nonblocking:
+ * @locked: whether the mmap_sem is still held
*
* This takes care of mlocking the pages too if VM_LOCKED is set.
*
@@ -1137,14 +1135,14 @@ static __always_inline long __get_user_pages_locked(struct task_struct *tsk,
*
* vma->vm_mm->mmap_sem must be held.
*
- * If @nonblocking is NULL, it may be held for read or write and will
+ * If @locked is NULL, it may be held for read or write and will
* be unperturbed.
*
- * If @nonblocking is non-NULL, it must held for read only and may be
- * released. If it's released, *@nonblocking will be set to 0.
+ * If @locked is non-NULL, it must held for read only and may be
+ * released. If it's released, *@locked will be set to 0.
*/
long populate_vma_page_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end, int *nonblocking)
+ unsigned long start, unsigned long end, int *locked)
{
struct mm_struct *mm = vma->vm_mm;
unsigned long nr_pages = (end - start) / PAGE_SIZE;
@@ -1179,7 +1177,7 @@ long populate_vma_page_range(struct vm_area_struct *vma,
* not result in a stack expansion that recurses back here.
*/
return __get_user_pages(current, mm, start, nr_pages, gup_flags,
- NULL, NULL, nonblocking);
+ NULL, NULL, locked);
}
/*
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index dd8737a94bec..c84f721db020 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4266,7 +4266,7 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm,
long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
struct page **pages, struct vm_area_struct **vmas,
unsigned long *position, unsigned long *nr_pages,
- long i, unsigned int flags, int *nonblocking)
+ long i, unsigned int flags, int *locked)
{
unsigned long pfn_offset;
unsigned long vaddr = *position;
@@ -4337,7 +4337,7 @@ long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
spin_unlock(ptl);
if (flags & FOLL_WRITE)
fault_flags |= FAULT_FLAG_WRITE;
- if (nonblocking)
+ if (locked)
fault_flags |= FAULT_FLAG_ALLOW_RETRY;
if (flags & FOLL_NOWAIT)
fault_flags |= FAULT_FLAG_ALLOW_RETRY |
@@ -4354,9 +4354,9 @@ long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
break;
}
if (ret & VM_FAULT_RETRY) {
- if (nonblocking &&
+ if (locked &&
!(fault_flags & FAULT_FLAG_RETRY_NOWAIT))
- *nonblocking = 0;
+ *locked = 0;
*nr_pages = 0;
/*
* VM_FAULT_RETRY must not return an
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] qemu-cpu-models.rst: Document -noTSX, mds-no, taa-no, and tsx-ctrl
From: Paolo Bonzini @ 2020-02-20 14:52 UTC (permalink / raw)
To: Kashyap Chamarthy, qemu-devel
Cc: peter.maydell, berrange, Eduardo Habkost, Richard Henderson
In-Reply-To: <20200220142001.20774-3-kchamart@redhat.com>
Two small changes...
On 20/02/20 15:20, Kashyap Chamarthy wrote:
> + Recommended to inform the guest that it can disable the Intel TSX
> + (Transactional Synchronization Extensions) feature; or, if the
> + processor is vulnerable, use the Intel VERW instruction (a
> + processor-level instruction that performs checks on memory access) as
> + a mitigation for the TAA vulnerability. (For details, refer to this
> + `Intel's deep-dive into
> + MDS <https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling>`_.)
... refer to Intel's `deep dive into MDS <...>`_.
(I don't know what the trailing underscore is for. I reaffirm my
definition of rST as the Perl of markup formats).
> +
> + Expose this to the guest OS if and only if: (a) the host has TSX
> + enabled; *and* (b) the guest has ``rtm`` CPU flag enabled.
> +
> + By disabling TSX, KVM-based guests can avoid paying the price of
> + mitigting TSX-based attacks.
"mitigating"
Paolo
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915/gt: Expand bad CS completion event debug
From: kbuild test robot @ 2020-02-20 14:54 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20200211230944.1203098-1-chris@chris-wilson.co.uk>
[-- Attachment #1: Type: text/plain, Size: 15533 bytes --]
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.6-rc2]
[cannot apply to drm-tip/drm-tip next-20200220]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-gt-Expand-bad-CS-completion-event-debug/20200215-041958
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-c002-20200220 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'process_csb':
>> drivers/gpu/drm/i915/gt/intel_lrc.c:2325:16: error: unused variable 'regs' [-Werror=unused-variable]
const u32 *regs = rq->context->lrc_reg_state;
^~~~
Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_read
Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_write
Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:arch_set_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:arch___set_bit
Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:arch_clear_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:arch_clear_bit_unlock
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:arch_test_and_set_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:variable_test_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:__ffs
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:ffs
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-atomic.h:set_bit
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-atomic.h:clear_bit
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-atomic.h:test_and_set_bit
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-non-atomic.h:__set_bit
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-lock.h:clear_bit_unlock
Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32
Cyclomatic Complexity 1 arch/x86/include/asm/div64.h:mul_u32_u32
Cyclomatic Complexity 1 arch/x86/include/asm/string_32.h:memset32
Cyclomatic Complexity 1 include/linux/string.h:memset_p
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_read
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_inc
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_dec
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_dec_and_test
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_fetch_add
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_fetch_sub
Cyclomatic Complexity 2 arch/x86/include/asm/atomic.h:arch_atomic_try_cmpxchg
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_read
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_fetch_add
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_fetch_sub
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_inc
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_dec
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_try_cmpxchg
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_dec_and_test
Cyclomatic Complexity 1 include/linux/atomic-fallback.h:atomic_fetch_inc
Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
Cyclomatic Complexity 1 include/linux/list.h:__list_del
Cyclomatic Complexity 1 include/linux/list.h:list_is_last
Cyclomatic Complexity 1 include/linux/list.h:list_empty
Cyclomatic Complexity 1 arch/x86/include/asm/special_insns.h:clflush
Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
Cyclomatic Complexity 1 include/linux/err.h:ERR_CAST
Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:native_irq_disable
Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:native_irq_enable
Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_local_irq_disable
Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_local_irq_enable
Cyclomatic Complexity 1 arch/x86/include/asm/processor.h:rep_nop
Cyclomatic Complexity 1 arch/x86/include/asm/processor.h:cpu_relax
Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_add
Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_sub
Cyclomatic Complexity 1 include/linux/bottom_half.h:__local_bh_disable_ip
Cyclomatic Complexity 1 include/linux/bottom_half.h:local_bh_disable
Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock_irq
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irq
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readl
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writel
Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_lock
Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_unlock
Cyclomatic Complexity 1 include/linux/rcupdate.h:rcu_read_lock
Cyclomatic Complexity 1 include/linux/rbtree.h:rb_link_node
Cyclomatic Complexity 3 include/linux/overflow.h:__ab_c_size
Cyclomatic Complexity 1 include/linux/seqlock.h:raw_write_seqcount_begin
Cyclomatic Complexity 1 include/linux/seqlock.h:raw_write_seqcount_end
Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies
Cyclomatic Complexity 1 include/linux/ktime.h:ktime_to_ns
Cyclomatic Complexity 3 include/linux/ktime.h:ktime_compare
Cyclomatic Complexity 1 include/linux/ktime.h:ktime_after
Cyclomatic Complexity 1 include/linux/timer.h:timer_pending
Cyclomatic Complexity 1 include/linux/interrupt.h:tasklet_disable_nosync
Cyclomatic Complexity 1 include/linux/interrupt.h:tasklet_enable
Cyclomatic Complexity 3 include/linux/slab.h:kmalloc_type
Cyclomatic Complexity 28 include/linux/slab.h:kmalloc_index
Cyclomatic Complexity 1 include/linux/slab.h:kmalloc_large
Cyclomatic Complexity 4 include/linux/slab.h:kmalloc
Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
Cyclomatic Complexity 1 include/linux/dma-resv.h:dma_resv_get_list
Cyclomatic Complexity 1 include/drm/drm_print.h:drm_info_printer
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_reg.h:i915_mmio_reg_offset
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_utils.h:msecs_to_jiffies_timeout
Cyclomatic Complexity 3 drivers/gpu/drm/i915/i915_utils.h:timer_expired
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_gem.h:__tasklet_is_enabled
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_gem.h:__tasklet_enable
Cyclomatic Complexity 1 drivers/gpu/drm/i915/gt/intel_engine_types.h:intel_engine_has_preemption
Cyclomatic Complexity 1 drivers/gpu/drm/i915/gt/intel_engine_types.h:intel_engine_has_semaphores
Cyclomatic Complexity 1 drivers/gpu/drm/i915/gt/intel_engine_types.h:intel_engine_has_relative_mmio
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_request.h:to_request
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_request.h:i915_seqno_passed
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_request.h:__hwsp_seqno
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_request.h:i915_request_is_ready
vim +/regs +2325 drivers/gpu/drm/i915/gt/intel_lrc.c
2212
2213 static void process_csb(struct intel_engine_cs *engine)
2214 {
2215 struct intel_engine_execlists * const execlists = &engine->execlists;
2216 const u32 * const buf = execlists->csb_status;
2217 const u8 num_entries = execlists->csb_size;
2218 u8 head, tail;
2219
2220 /*
2221 * As we modify our execlists state tracking we require exclusive
2222 * access. Either we are inside the tasklet, or the tasklet is disabled
2223 * and we assume that is only inside the reset paths and so serialised.
2224 */
2225 GEM_BUG_ON(!tasklet_is_locked(&execlists->tasklet) &&
2226 !reset_in_progress(execlists));
2227 GEM_BUG_ON(!intel_engine_in_execlists_submission_mode(engine));
2228
2229 /*
2230 * Note that csb_write, csb_status may be either in HWSP or mmio.
2231 * When reading from the csb_write mmio register, we have to be
2232 * careful to only use the GEN8_CSB_WRITE_PTR portion, which is
2233 * the low 4bits. As it happens we know the next 4bits are always
2234 * zero and so we can simply masked off the low u8 of the register
2235 * and treat it identically to reading from the HWSP (without having
2236 * to use explicit shifting and masking, and probably bifurcating
2237 * the code to handle the legacy mmio read).
2238 */
2239 head = execlists->csb_head;
2240 tail = READ_ONCE(*execlists->csb_write);
2241 ENGINE_TRACE(engine, "cs-irq head=%d, tail=%d\n", head, tail);
2242 if (unlikely(head == tail))
2243 return;
2244
2245 /*
2246 * Hopefully paired with a wmb() in HW!
2247 *
2248 * We must complete the read of the write pointer before any reads
2249 * from the CSB, so that we do not see stale values. Without an rmb
2250 * (lfence) the HW may speculatively perform the CSB[] reads *before*
2251 * we perform the READ_ONCE(*csb_write).
2252 */
2253 rmb();
2254
2255 do {
2256 bool promote;
2257
2258 if (++head == num_entries)
2259 head = 0;
2260
2261 /*
2262 * We are flying near dragons again.
2263 *
2264 * We hold a reference to the request in execlist_port[]
2265 * but no more than that. We are operating in softirq
2266 * context and so cannot hold any mutex or sleep. That
2267 * prevents us stopping the requests we are processing
2268 * in port[] from being retired simultaneously (the
2269 * breadcrumb will be complete before we see the
2270 * context-switch). As we only hold the reference to the
2271 * request, any pointer chasing underneath the request
2272 * is subject to a potential use-after-free. Thus we
2273 * store all of the bookkeeping within port[] as
2274 * required, and avoid using unguarded pointers beneath
2275 * request itself. The same applies to the atomic
2276 * status notifier.
2277 */
2278
2279 ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
2280 head, buf[2 * head + 0], buf[2 * head + 1]);
2281
2282 if (INTEL_GEN(engine->i915) >= 12)
2283 promote = gen12_csb_parse(execlists, buf + 2 * head);
2284 else
2285 promote = gen8_csb_parse(execlists, buf + 2 * head);
2286 if (promote) {
2287 struct i915_request * const *old = execlists->active;
2288
2289 /* Point active to the new ELSP; prevent overwriting */
2290 WRITE_ONCE(execlists->active, execlists->pending);
2291
2292 if (!inject_preempt_hang(execlists))
2293 ring_set_paused(engine, 0);
2294
2295 /* cancel old inflight, prepare for switch */
2296 trace_ports(execlists, "preempted", old);
2297 while (*old)
2298 execlists_schedule_out(*old++);
2299
2300 /* switch pending to inflight */
2301 GEM_BUG_ON(!assert_pending_valid(execlists, "promote"));
2302 WRITE_ONCE(execlists->active,
2303 memcpy(execlists->inflight,
2304 execlists->pending,
2305 execlists_num_ports(execlists) *
2306 sizeof(*execlists->pending)));
2307
2308 WRITE_ONCE(execlists->pending[0], NULL);
2309 } else {
2310 GEM_BUG_ON(!*execlists->active);
2311
2312 /* port0 completed, advanced to port1 */
2313 trace_ports(execlists, "completed", execlists->active);
2314
2315 /*
2316 * We rely on the hardware being strongly
2317 * ordered, that the breadcrumb write is
2318 * coherent (visible from the CPU) before the
2319 * user interrupt and CSB is processed.
2320 */
2321 if (GEM_SHOW_DEBUG() &&
2322 !i915_request_completed(*execlists->active) &&
2323 !reset_in_progress(execlists)) {
2324 struct i915_request *rq = *execlists->active;
> 2325 const u32 *regs = rq->context->lrc_reg_state;
2326
2327 ENGINE_TRACE(engine,
2328 "ring:{start:0x%08x, head:%04x, tail:%04x, ctl:%08x, mode:%08x}\n",
2329 ENGINE_READ(engine, RING_START),
2330 ENGINE_READ(engine, RING_HEAD) & HEAD_ADDR,
2331 ENGINE_READ(engine, RING_TAIL) & TAIL_ADDR,
2332 ENGINE_READ(engine, RING_CTL),
2333 ENGINE_READ(engine, RING_MI_MODE));
2334 ENGINE_TRACE(engine,
2335 "rq:{start:%08x, head:%04x, tail:%04x, seqno:%llx:%d, hwsp:%d}, ",
2336 i915_ggtt_offset(rq->ring->vma),
2337 rq->head, rq->tail,
2338 rq->fence.context,
2339 lower_32_bits(rq->fence.seqno),
2340 hwsp_seqno(rq));
2341 ENGINE_TRACE(engine,
2342 "ctx:{start:%08x, head:%04x, tail:%04x}, ",
2343 regs[CTX_RING_START],
2344 regs[CTX_RING_HEAD],
2345 regs[CTX_RING_TAIL]);
2346
2347 GEM_BUG_ON("context completed before request");
2348 }
2349
2350 execlists_schedule_out(*execlists->active++);
2351
2352 GEM_BUG_ON(execlists->active - execlists->inflight >
2353 execlists_num_ports(execlists));
2354 }
2355 } while (head != tail);
2356
2357 execlists->csb_head = head;
2358 set_timeslice(engine);
2359
2360 /*
2361 * Gen11 has proven to fail wrt global observation point between
2362 * entry and tail update, failing on the ordering and thus
2363 * we see an old entry in the context status buffer.
2364 *
2365 * Forcibly evict out entries for the next gpu csb update,
2366 * to increase the odds that we get a fresh entries with non
2367 * working hardware. The cost for doing so comes out mostly with
2368 * the wash as hardware, working or not, will need to do the
2369 * invalidation before.
2370 */
2371 invalidate_csb_entries(&buf[0], &buf[num_entries - 1]);
2372 }
2373
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 39450 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.