Re: FYI: Userland breakage caused by udev bind commit
On Mon, Dec 24, 2018 at 10:13 AM Christian Brauner wrote: > > So one possibility is to add a socket option for lib/kobject_uevent.c > that can be set via setsockopt. We did something like this in netlink > for strict property and header checking without breaking backwards > compatibility. I'd actually prefer for it to be some /sys interface or other. Maybe it could even be per-device or class, and you could do something like echo "enable bind" > /sys/bus/serio/uevent the uevent code already supports a per-node "filter" function, maybe that notion could be extended to also have a filter for uevent types. But I'm just handwaving. Maybe it's better per uevent socket or something. Linus
[PATCH] infiniband/qedr: Potential null ptr dereference of qp
idr_find() may fail and return a NULL pointer. The fix checks the return value of the function and returns an error in case of NULL. Signed-off-by: Aditya Pakki --- drivers/infiniband/hw/qedr/qedr_iw_cm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/infiniband/hw/qedr/qedr_iw_cm.c b/drivers/infiniband/hw/qedr/qedr_iw_cm.c index 505fa3648762..93b16237b767 100644 --- a/drivers/infiniband/hw/qedr/qedr_iw_cm.c +++ b/drivers/infiniband/hw/qedr/qedr_iw_cm.c @@ -492,6 +492,8 @@ int qedr_iw_connect(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param) int i; qp = idr_find(>qpidr.idr, conn_param->qpn); + if (unlikely(!qp)) + return -EINVAL; laddr = (struct sockaddr_in *)_id->m_local_addr; raddr = (struct sockaddr_in *)_id->m_remote_addr; -- 2.17.1
Re: FYI: Userland breakage caused by udev bind commit
On Mon, Dec 24, 2018 at 10:06:54AM -0800, Linus Torvalds wrote: > On Mon, Dec 24, 2018 at 9:34 AM Dmitry Torokhov > wrote: > > > > Well, it appears that we can no longer extend uevent interface with new > > types of uevents, at least not until we go and fix up all > > udev-derivatives and give some time for things to settle. > > How about having the users "opt in" for new events some way? > > Do all the legacy events by default, but then if some user wants a > "bind" event (or some other new event) add a model for the uevent > interface to actually enable it. So one possibility is to add a socket option for lib/kobject_uevent.c that can be set via setsockopt. We did something like this in netlink for strict property and header checking without breaking backwards compatibility. That might be an option: commit cd7f7df6ca3366be4ac79e824fdaa8d482270015 Merge: 272a66173bbc 8c6e137fbc7f Author: David S. Miller Date: Mon Oct 8 10:39:06 2018 -0700 Merge branch 'rtnetlink-Add-support-for-rigid-checking-of-data-in-dump-request' David Ahern says: rtnetlink: Add support for rigid checking of data in dump request https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=cd7f7df6ca3366be4ac79e824fdaa8d482270015 or adding a new flag that can be passed when opening a NETLINK_KOBJECT_UEVENT socket. Christian > > Not using kernel versioning (nothing should *ever* look at the kernel > version, since that makes things like backports a huge and > insurmountable pain), but simply using some specific control channel. > > > I guess reverting is the right solution here. I wish folks would yell > > earlier though... > > So nobody is actually using the new "bind" event, I take it? It's > about a year and a half, and it's in 4.14 which is widely used, so > reverting it has a risk too. > > Which is why I too would hope people would be much more vocal about > "that broke my setup". > > But reverting does sound like the right thing to do if nobody is using > it. It sounds like systemd udev does not, and if eudev is actively > broken by this then how many other cases might there be? > > I assume any locally modified udev rules would still be ok with the > revert (since presumably any udev rule modification people did was to > just ignore the bind/unbind events that no longer would be sent). > > Linus
Re: [PATCH net-next 0/3] vhost: accelerate metadata access through vmap()
On Mon, Dec 24, 2018 at 04:32:39PM +0800, Jason Wang wrote: > > On 2018/12/14 下午8:33, Michael S. Tsirkin wrote: > > On Fri, Dec 14, 2018 at 11:42:18AM +0800, Jason Wang wrote: > > > On 2018/12/13 下午11:27, Michael S. Tsirkin wrote: > > > > On Thu, Dec 13, 2018 at 06:10:19PM +0800, Jason Wang wrote: > > > > > Hi: > > > > > > > > > > This series tries to access virtqueue metadata through kernel virtual > > > > > address instead of copy_user() friends since they had too much > > > > > overheads like checks, spec barriers or even hardware feature > > > > > toggling. > > > > Userspace accesses through remapping tricks and next time there's a need > > > > for a new barrier we are left to figure it out by ourselves. > > > > > > I don't get here, do you mean spec barriers? > > I mean the next barrier people decide to put into userspace > > memory accesses. > > > > > It's completely unnecessary for > > > vhost which is kernel thread. > > It's defence in depth. Take a look at the commit that added them. > > And yes quite possibly in most cases we actually have a spec > > barrier in the validation phase. If we do let's use the > > unsafe variants so they can be found. > > > unsafe variants can only work if you can batch userspace access. This is not > necessarily the case for light load. Do we care a lot about the light load? How would you benchmark it? > > > > > > And even if you're right, vhost is not the > > > only place, there's lots of vmap() based accessing in kernel. > > For sure. But if one can get by without get user pages, one > > really should. Witness recently uncovered mess with file > > backed storage. > > > We only pin metadata pages, I don't believe they will be used by any DMA. It doesn't matter really, if you dirty pages behind the MM back the problem is there. > > > > > > Think in > > > another direction, this means we won't suffer form unnecessary barriers > > > for > > > kthread like vhost in the future, we will manually pick the one we really > > > need > > I personally think we should err on the side of caution not on the side of > > performance. > > > So what you suggest may lead unnecessary performance regression (10%-20%) > which is part of the goal of this series. We should audit and only use the > one we really need instead of depending on copy_user() friends(). > > If we do it our own, it could be slow for for security fix but it's no less > safe than before with performance kept. > > > > > > > (but it should have little possibility). > > History seems to teach otherwise. > > > What case did you mean here? > > > > > > > Please notice we only access metdata through remapping not the data > > > itself. > > > This idea has been used for high speed userspace backend for years, e.g > > > packet socket or recent AF_XDP. > > I think their justification for the higher risk is that they are mostly > > designed for priveledged userspace. > > > I think it's the same with TUN/TAP, privileged process can pass them to > unprivileged ones. > > > > > > > The only difference is the page was remap to > > > from kernel to userspace. > > At least that avoids the g.u.p mess. > > > I'm still not very clear at the point. We only pin 2 or 4 pages, they're > several other cases that will pin much more. > > > > > > > > I don't > > > > like the idea I have to say. As a first step, why don't we switch to > > > > unsafe_put_user/unsafe_get_user etc? > > > > > > Several reasons: > > > > > > - They only have x86 variant, it won't have any difference for the rest of > > > architecture. > > Is there an issue on other architectures? If yes they can be extended > > there. > > > Consider the unexpected amount of work and in the best case it can give the > same performance to vmap(). I'm not sure it's worth. > > > > > > > - unsafe_put_user/unsafe_get_user is not sufficient for accessing > > > structures > > > (e.g accessing descriptor) or arrays (batching). > > So you want unsafe_copy_xxx_user? I can do this. Hang on will post. > > > > > - Unless we can batch at least the accessing of two places in three of > > > avail, used and descriptor in one run. There will be no difference. E.g we > > > can batch updating used ring, but it won't make any difference in this > > > case. > > > > > So let's batch them all? > > > Batching might not help for the case of light load. And we need to measure > the gain/cost of batching itself. > > > > > > > > > > That would be more of an apples to apples comparison, would it not? > > > > > > Apples to apples comparison only help if we are the No.1. But the fact is > > > we > > > are not. If we want to compete with e.g dpdk or AF_XDP, vmap() is the > > > fastest method AFAIK. > > > > > > > > > Thanks > > We need to speed up the packet access itself too though. > > You can't vmap all of guest memory. > > > This series only pin and vmap very few pages (metadata). > > Thanks > > > > > > > > > > > > > > > Test shows about 24%
Re: [PATCH] drivers/net: appletalk/cops: remove redundant if statement and mask
On 24/12/2018 18:08, David Miller wrote: > From: Colin King > Date: Sat, 22 Dec 2018 16:58:41 + > >> @@ -777,10 +777,7 @@ static void cops_rx(struct net_device *dev) >> } >> >> /* Get response length. */ >> -if(lp->board==DAYNA) >> -pkt_len = inb(ioaddr) & 0xFF; >> -else >> -pkt_len = inb(ioaddr) & 0x00FF; >> +pkt_len = inb(ioaddr); > > There are other instances of similar weird identical statements guarded > by the test on the board type being DAYNA. > > For example, in cops_send_packet(): > > if(lp->board == DAYNA) > outb(skb->len >> 8, ioaddr); > else > outb((skb->len >> 8)&0x0FF, ioaddr); > > Could you scan the rest of the driver and deal with all of these > instances in one go? Will do, probably in a day or so. > > Thank you! >
Re: [PATCH net-next 3/3] vhost: access vq metadata through kernel virtual address
On Mon, Dec 24, 2018 at 03:53:16PM +0800, Jason Wang wrote:
>
> On 2018/12/14 下午8:36, Michael S. Tsirkin wrote:
> > On Fri, Dec 14, 2018 at 11:57:35AM +0800, Jason Wang wrote:
> > > On 2018/12/13 下午11:44, Michael S. Tsirkin wrote:
> > > > On Thu, Dec 13, 2018 at 06:10:22PM +0800, Jason Wang wrote:
> > > > > It was noticed that the copy_user() friends that was used to access
> > > > > virtqueue metdata tends to be very expensive for dataplane
> > > > > implementation like vhost since it involves lots of software check,
> > > > > speculation barrier, hardware feature toggling (e.g SMAP). The
> > > > > extra cost will be more obvious when transferring small packets.
> > > > >
> > > > > This patch tries to eliminate those overhead by pin vq metadata pages
> > > > > and access them through vmap(). During SET_VRING_ADDR, we will setup
> > > > > those mappings and memory accessors are modified to use pointers to
> > > > > access the metadata directly.
> > > > >
> > > > > Note, this was only done when device IOTLB is not enabled. We could
> > > > > use similar method to optimize it in the future.
> > > > >
> > > > > Tests shows about ~24% improvement on TX PPS when using virtio-user +
> > > > > vhost_net + xdp1 on TAP (CONFIG_HARDENED_USERCOPY is not enabled):
> > > > >
> > > > > Before: ~5.0Mpps
> > > > > After: ~6.1Mpps
> > > > >
> > > > > Signed-off-by: Jason Wang
> > > > > ---
> > > > >drivers/vhost/vhost.c | 178
> > > > > ++
> > > > >drivers/vhost/vhost.h | 11 +++
> > > > >2 files changed, 189 insertions(+)
> > > > >
> > > > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > > > index bafe39d2e637..1bd24203afb6 100644
> > > > > --- a/drivers/vhost/vhost.c
> > > > > +++ b/drivers/vhost/vhost.c
> > > > > @@ -443,6 +443,9 @@ void vhost_dev_init(struct vhost_dev *dev,
> > > > > vq->indirect = NULL;
> > > > > vq->heads = NULL;
> > > > > vq->dev = dev;
> > > > > + memset(>avail_ring, 0, sizeof(vq->avail_ring));
> > > > > + memset(>used_ring, 0, sizeof(vq->used_ring));
> > > > > + memset(>desc_ring, 0, sizeof(vq->desc_ring));
> > > > > mutex_init(>mutex);
> > > > > vhost_vq_reset(dev, vq);
> > > > > if (vq->handle_kick)
> > > > > @@ -614,6 +617,102 @@ static void vhost_clear_msg(struct vhost_dev
> > > > > *dev)
> > > > > spin_unlock(>iotlb_lock);
> > > > >}
> > > > > +static int vhost_init_vmap(struct vhost_vmap *map, unsigned long
> > > > > uaddr,
> > > > > +size_t size, int write)
> > > > > +{
> > > > > + struct page **pages;
> > > > > + int npages = DIV_ROUND_UP(size, PAGE_SIZE);
> > > > > + int npinned;
> > > > > + void *vaddr;
> > > > > +
> > > > > + pages = kmalloc_array(npages, sizeof(struct page *),
> > > > > GFP_KERNEL);
> > > > > + if (!pages)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + npinned = get_user_pages_fast(uaddr, npages, write, pages);
> > > > > + if (npinned != npages)
> > > > > + goto err;
> > > > > +
> > > > As I said I have doubts about the whole approach, but this
> > > > implementation in particular isn't a good idea
> > > > as it keeps the page around forever.
>
>
> The pages wil be released during set features.
>
>
> > > > So no THP, no NUMA rebalancing,
>
>
> For THP, we will probably miss 2 or 4 pages, but does this really matter
> consider the gain we have?
We as in vhost? networking isn't the only thing guest does.
We don't even know if this guest does a lot of networking.
You don't
know what else is in this huge page. Can be something very important
that guest touches all the time.
> For NUMA rebalancing, I'm even not quite sure if
> it can helps for the case of IPC (vhost). It looks to me the worst case it
> may cause page to be thrash between nodes if vhost and userspace are running
> in two nodes.
So again it's a gain for vhost but has a completely unpredictable effect on
other functionality of the guest.
That's what bothers me with this approach.
>
> > >
> > > This is the price of all GUP users not only vhost itself.
> > Yes. GUP is just not a great interface for vhost to use.
>
>
> Zerocopy codes (enabled by defualt) use them for years.
But only for TX and temporarily. We pin, read, unpin.
Your patch is different
- it writes into memory and GUP has known issues with file
backed memory
- it keeps pages pinned forever
>
> >
> > > What's more
> > > important, the goal is not to be left too much behind for other backends
> > > like DPDK or AF_XDP (all of which are using GUP).
> >
> > So these guys assume userspace knows what it's doing.
> > We can't assume that.
>
>
> What kind of assumption do you they have?
>
>
> >
> > > > userspace-controlled
> > > > amount of memory locked up and not accounted for.
> > >
> > > It's pretty easy to add this since the
Re: [PATCH] drivers/net: appletalk/cops: remove redundant if statement and mask
From: Colin King Date: Sat, 22 Dec 2018 16:58:41 + > @@ -777,10 +777,7 @@ static void cops_rx(struct net_device *dev) > } > > /* Get response length. */ > - if(lp->board==DAYNA) > - pkt_len = inb(ioaddr) & 0xFF; > - else > - pkt_len = inb(ioaddr) & 0x00FF; > + pkt_len = inb(ioaddr); There are other instances of similar weird identical statements guarded by the test on the board type being DAYNA. For example, in cops_send_packet(): if(lp->board == DAYNA) outb(skb->len >> 8, ioaddr); else outb((skb->len >> 8)&0x0FF, ioaddr); Could you scan the rest of the driver and deal with all of these instances in one go? Thank you!
Re: FYI: Userland breakage caused by udev bind commit
On Mon, Dec 24, 2018 at 9:34 AM Dmitry Torokhov wrote: > > Well, it appears that we can no longer extend uevent interface with new > types of uevents, at least not until we go and fix up all > udev-derivatives and give some time for things to settle. How about having the users "opt in" for new events some way? Do all the legacy events by default, but then if some user wants a "bind" event (or some other new event) add a model for the uevent interface to actually enable it. Not using kernel versioning (nothing should *ever* look at the kernel version, since that makes things like backports a huge and insurmountable pain), but simply using some specific control channel. > I guess reverting is the right solution here. I wish folks would yell > earlier though... So nobody is actually using the new "bind" event, I take it? It's about a year and a half, and it's in 4.14 which is widely used, so reverting it has a risk too. Which is why I too would hope people would be much more vocal about "that broke my setup". But reverting does sound like the right thing to do if nobody is using it. It sounds like systemd udev does not, and if eudev is actively broken by this then how many other cases might there be? I assume any locally modified udev rules would still be ok with the revert (since presumably any udev rule modification people did was to just ignore the bind/unbind events that no longer would be sent). Linus
Re: [PATCH] net/mlx5e: fix semicolon.cocci warnings
From: Leon Romanovsky Date: Sun, 23 Dec 2018 09:06:13 +0200 > Can you please apply this small fix? Sure, I (eventually) will. I'm just trying to figure out a few procedural issues with handling the early net-next pull request before I start tossing more changes on top. Thanks!
Re: [PATCH net-next] staging: octeon: fix build failure with XFRM enabled
From: Florian Westphal
Date: Fri, 21 Dec 2018 21:57:26 +0100
> skb->sp doesn't exist anymore in the next-next tree, so mips defconfig
> no longer builds. Use helper instead to reset the secpath.
>
> Not even compile tested.
>
> Cc: Greg Kroah-Hartman
> Reported-by: Guenter Roeck
> Fixes: 4165079ba328d ("net: switch secpath to use skb extension
> infrastructure")
> Signed-off-by: Florian Westphal
> ---
> Greg, David:
>
> The patch will not break build for a tree that lacks the 'Fixes'
> commit, so this can also go in via staging tree.
> OTOH, net-next build is broken for mips/octeon, so I think in
> this case net-next might make more sense?
Yeah I agree, that net-next is probably the best place for this.
Because I know that Linus is sensitive to situations where he is
sent a pull request, and then what he pulls doesn't match the pull
request shortlog etc. I have asked him how he would let me handle
this.
That's the only reason I haven't integrated this yet.
Just FYI!
[PATCH] batman-adv/main: Fix check on return value of rtnl_link_register
rtnl_link_register() may fail and can impact registering the device.
The fix checks the return value and pushes the error upstream.
Signed-off-by: Aditya Pakki
---
net/batman-adv/main.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/batman-adv/main.c b/net/batman-adv/main.c
index 69c0d85bceb3..e0007f242823 100644
--- a/net/batman-adv/main.c
+++ b/net/batman-adv/main.c
@@ -109,7 +109,10 @@ static int __init batadv_init(void)
batadv_debugfs_init();
register_netdevice_notifier(_hard_if_notifier);
- rtnl_link_register(_link_ops);
+ ret = rtnl_link_register(_link_ops);
+ if (ret < 0)
+ return ret;
+
batadv_netlink_register();
pr_info("B.A.T.M.A.N. advanced %s (compatibility version %i) loaded\n",
--
2.17.1
[PATCH] dma/mv_xor: Fix a missing check in mv_xor_channel_add
dma_async_device_register() may fail and return an error. The capabilities checked in mv_xor_channel_add() are not complete. The fix handles the error by freeing the resources. Signed-off-by: Aditya Pakki --- drivers/dma/mv_xor.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c index 7f595355fb79..e733c5eeaabc 100644 --- a/drivers/dma/mv_xor.c +++ b/drivers/dma/mv_xor.c @@ -1153,7 +1153,10 @@ mv_xor_channel_add(struct mv_xor_device *xordev, dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "", dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : ""); - dma_async_device_register(dma_dev); + ret = dma_async_device_register(dma_dev); + if (ret) + goto err_free_irq; + return mv_chan; err_free_irq: -- 2.17.1
Re: [PATCH net V2 4/4] vhost: log dirty page correctly
On Mon, Dec 24, 2018 at 11:43:31AM +0800, Jason Wang wrote: > > On 2018/12/14 下午9:20, Michael S. Tsirkin wrote: > > On Fri, Dec 14, 2018 at 10:43:03AM +0800, Jason Wang wrote: > > > On 2018/12/13 下午10:31, Michael S. Tsirkin wrote: > > > > > Just to make sure I understand this. It looks to me we should: > > > > > > > > > > - allow passing GIOVA->GPA through UAPI > > > > > > > > > > - cache GIOVA->GPA somewhere but still use GIOVA->HVA in device IOTLB > > > > > for > > > > > performance > > > > > > > > > > Is this what you suggest? > > > > > > > > > > Thanks > > > > Not really. We already have GPA->HVA, so I suggested a flag to pass > > > > GIOVA->GPA in the IOTLB. > > > > > > > > This has advantages for security since a single table needs > > > > then to be validated to ensure guest does not corrupt > > > > QEMU memory. > > > > > > > I wonder how much we can gain through this. Currently, qemu IOMMU gives > > > GIOVA->GPA mapping, and qemu vhost code will translate GPA to HVA then > > > pass > > > GIOVA->HVA to vhost. It looks no difference to me. > > > > > > Thanks > > The difference is in security not in performance. Getting a bad HVA > > corrupts QEMU memory and it might be guest controlled. Very risky. > > > How can this be controlled by guest? HVA was generated from qemu ram blocks > which is totally under the control of qemu memory core instead of guest. > > > Thanks It is ultimately under guest influence as guest supplies IOVA->GPA translations. qemu translates GPA->HVA and gives the translated result to the kernel. If it's not buggy and kernel isn't buggy it's all fine. But that's the approach that was proven not to work in the 20th century. In the 21st century we are trying defence in depth approach. My point is that a single code path that is responsible for the HVA translations is better than two. > > > If > > translations to HVA are done in a single place through a single table > > it's safer as there's a single risky place. > >
Re: FYI: Userland breakage caused by udev bind commit
On Mon, Dec 24, 2018 at 11:54:07AM +0100, Greg KH wrote:
> On Mon, Dec 24, 2018 at 11:15:34AM +0100, Gabriel C wrote:
> > Am Mo., 24. Dez. 2018 um 10:17 Uhr schrieb Greg KH
> > :
> > >
> > > On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote:
> > > > Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov
> > > > :
> > > >
> > > > [ also added Linus to CC on that one too ]
> > > > >
> > > > > On Sun, Dec 23, 2018 at 06:17:04PM +0100, Christian Brauner wrote:
> > > > > > On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am the maintainer of libmtp and libgphoto2
> > > > > > >
> > > > > > > Some months ago I was made aware of this bug:
> > > > > > > https://bugs.kde.org/show_bug.cgi?id=387454
> > > > > > >
> > > > > > > This was fallout identified to come from this kernel commit:
> > > > > > >
> > > > > > > commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65
> > > > > > > Author: Dmitry Torokhov
> > > > > > > Date: Wed Jul 19 17:24:30 2017 -0700
> > > > > >
> > > > > > Fwiw, the addition of {un}bind events has caused issues for
> > > > > > systemd-udevd as well and is tracked here:
> > > > > > https://github.com/systemd/systemd/issues/7587
> > > > > > I haven't been aware of this until yesterday and it seems that so
> > > > > > far
> > > > > > this hasn't been brought up on lkml until you did now.
> > > > >
> > > > > The fallout was caused by premature enabling of the new events in
> > > > > systemd/udev by yours truly (even though the commit has Lennart's name
> > > > > on it due to how it was merged):
> > > > >
> > > > > https://github.com/systemd/systemd/commit/9a39e1ce314d1a6f8a754f6dab040019239666a9
> > > > >
> > > > > "Add handling for bind/unbind actions (#6720)
> > > > >
> > > > > Newer kernels will emit uevents with "bind" and "unbind" actions.
> > > > > These
> > > > > uevents will be issued when driver is bound to or unbound from a
> > > > > device.
> > > > > "Bind" events are helpful when device requires a firmware to operate
> > > > > properly, and driver is unable to create a child device before
> > > > > firmware
> > > > > is properly loaded.
> > > > >
> > > > > For some reason systemd validates actions and drops the ones it does
> > > > > not
> > > > > know, instead of passing them on through as old udev did, so we need
> > > > > to
> > > > > explicitly teach it about them."
> > > > >
> > > > > Similarly it is now papered over in systemd/udev until we make it
> > > > > properly handle new events:
> > > > >
> > > > > https://github.com/systemd/systemd/commit/56c886dc7ed5b2bb0882ba85136f4070545bfc1b
> > > > >
> > > > > "sd-device: ignore bind/unbind events for now
> > > > >
> > > > > Until systemd/udev are ready for the new events and do not flush
> > > > > entire
> > > > > device state on each new event received, we should ignore them."
> > > > >
> > > >
> > > > And how about peoples still uses systemd < 235 and newer kernels ?
> > >
> > > Is that an issue? Who uses that, and does it cause problems on their
> > > systems given that the events just do not do anything for those systems?
> > >
> > > We tested this out a lot back in the summer of 2017 and I thought all
> > > was well. What recently changed that caused breakages to suddenly show
> > > up? How have we not seen this until now?
> > >
> >
> > Well people observed that , please click the bug link for that KDE bug.
> > Reported '2017-11-30'..
> >
> > I can reproduce that on systemd 231 ( which we have here ) and
> > kernels >= 4.14 just easy.
> >
> > Can't use any mtp devices all dropping :
> >
> > The file or folder udi=/org/kde/solid/udev/... does not exists'
> >
> > Why it got not reported here is probably because people are shy to
> > report such things to LKML.
> >
> > > We can drop the "new" uevents now by reverting the patch, but what about
> > > the userspace tools that now depend on them as we have had them in our
> > > kernels for so long? We can't now break them, right? Should we add a
> > > new kernel config option to not emit those for older userspaces that can
> > > not handle this (of which I really still do not understand given that we
> > > tested the heck out of this last year...)
> >
> > Peoples started to add workarounds to make it work somewhat again.
> >
> > Greg any such changes to udev are very fragile.
>
> I am not changing udev. Well, Dmitry changed udev, and then reverted
> it, so all should be fine :)
>
> > Also dropping some patch to systemd-udev won't solve anything on such moves.
>
> If systemd-udev was broken, it should resolve the issue, right?
>
> > Remember there exists other udev impelmentations too and not only that.
>
> Ok, what other udev implementations are broken and why have we not heard
> from them in the past 1 1/2 years?
>
> > See example below :
> >
> > app1- xxx - depending on some udev / kernel behaviour ( add rule in this
> > case )
> > kernel - xxx changes that (
[PATCH] misc/ics932s401: Add a missing check to i2c_smbus_read_word_data
ics932s401_update_device may fail reading in i2c_smbus_read_word_data
due to error in i2c_smbus_xfer. The fix checks the status and defaults
the register to 0.
Signed-off-by: Aditya Pakki
---
drivers/misc/ics932s401.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/ics932s401.c b/drivers/misc/ics932s401.c
index 81a0541ef3ac..294fb2f66bfe 100644
--- a/drivers/misc/ics932s401.c
+++ b/drivers/misc/ics932s401.c
@@ -146,6 +146,8 @@ static struct ics932s401_data
*ics932s401_update_device(struct device *dev)
*/
for (i = 0; i < NUM_MIRRORED_REGS; i++) {
temp = i2c_smbus_read_word_data(client, regs_to_copy[i]);
+ if (temp < 0)
+ data->regs[regs_to_copy[i]] = 0;
data->regs[regs_to_copy[i]] = temp >> 8;
}
--
2.17.1
[PATCH -next] ACPI/IORT: fix build when CONFIG_IOMMU_API=n
rivers/acpi/arm64/iort.c:880:1: error: expected identifier or '(' before '{'
token
{ return NULL; }
^
drivers/acpi/arm64/iort.c:879:39: warning: 'iort_fwspec_iommu_ops' used but
never defined
static inline const struct iommu_ops *iort_fwspec_iommu_ops(struct device
*dev);
^
Signed-off-by: Qian Cai
---
drivers/acpi/arm64/iort.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index fdd90ffceb85..5d29783ee5bd 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -876,7 +876,7 @@ int iort_iommu_msi_get_resv_regions(struct device *dev,
struct list_head *head)
return (resv == its->its_count) ? resv : -ENODEV;
}
#else
-static inline const struct iommu_ops *iort_fwspec_iommu_ops(struct device
*dev);
+static inline const struct iommu_ops *iort_fwspec_iommu_ops(struct device *dev)
{ return NULL; }
static inline int iort_add_device_replay(const struct iommu_ops *ops,
struct device *dev)
--
2.17.2 (Apple Git-113)
[GIT PULL] first round of SCSI updates for the 4.20+ merge window
This is mostly update of the usual drivers: smarpqi, lpfc, qedi, megaraid_sas, libsas, zfcp, mpt3sas, hisi_sas. Additionally, we have a pile of annotation, unused variable and minor updates. The big API change is the updates for Christoph's DMA rework which include removing the DISABLE_CLUSTERING flag. And finally there are a couple of target tree updates. Note: there is a merge conflict caused local commit c4e521b654e15e "scsi: qla2xxx: Split the __qla2x00_abort_all_cmds() function" clashing with upstream f2ffd4e5bc7b "scsi: qla2xxx: Timeouts occur on surprise removal of QLogic adapter". The resolution is the obvious one: to update the moved code, but also to remove the now unused status variable from __qla2x00_abort_all_cmds(). I've attached it below just in case you want to see it. We had some late arriving commits, but I've verified they've all had at least one linux-next run. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc The short changelog is: Ajish Koshy (2): scsi: smartpqi: allow for larger raid maps scsi: smartpqi: add support for huawei controllers Anatoliy Glagolev (1): scsi: qla2xxx: deadlock by configfs_depend_item Anil Gurumurthy (1): scsi: qla2xxx: Enable FC-NVME on NPIV ports Arnd Bergmann (3): scsi: aacraid: change event_wait to a completion scsi: aacraid: change wait_sem to a completion scsi: cxgb4i: fix thermal configuration dependencies Avri Altman (1): scsi: ufs: Remove redundant sense size definition Bart Van Assche (13): scsi: virtio_scsi: Remove per-target data because it is no longer used scsi: qla2xxx: Split the __qla2x00_abort_all_cmds() function scsi: target/core: Reduce the amount of code executed with a spinlock held scsi: target/core: Make ABORT and LUN RESET handling synchronous scsi: target/core: Fix TAS handling for aborted commands scsi: target/core: Simplify the code for aborting SCSI commands scsi: target/core: Make it possible to wait from more than one context for command completion scsi: target/core: Use system workqueues for TMF scsi: target/core: Make sure that target_wait_for_sess_cmds() waits long enough scsi: target/core: Simplify transport_clear_lun_ref() scsi: target/core: Use kvcalloc() instead of open-coding it scsi: target/tcmu: Fix queue_cmd_ring() declaration scsi: qla2xxx: Introduce a switch/case statement in qlt_xmit_tm_rsp() Chengguang Xu (2): scsi: qla4xxx: remvoe unnecessary condition check for mempool_destroy() scsi: qla4xxx: remove unnecessary condition check for dma_pool_destroy() Christoph Hellwig (36): scsi: myrs: remove the dma_boundary_limit scsi: myrb: remove the dma_boundary limit scsi: block: remove the cluster flag scsi: remove the use_clustering flag scsi: mac53c94: remove DISABLE_CLUSTERING scsi: mesh: remove DISABLE_CLUSTERING scsi: xen-scsifront: remove DISABLE_CLUSTERING scsi: powertec: remove the explicit use_clustering setting scsi: cumana_2: remove the explicit use_clustering setting scsi: introduce a max_segment_size host_template parameters scsi: flip the default on use_clustering scsi: make sure all drivers set the use_clustering flag scsi: aha1542: convert to DMA mapping API scsi: wd719x: always use generic DMA API scsi: wd719x: use per-command private data scsi: wd719x: there should be no active SCBs on removal scsi: sym53c8xx: use dma_set_mask scsi: stex: use dma_set_mask_and_coherent scsi: mvumi: use dma_set_mask scsi: lpfc: use dma_set_mask_and_coherent scsi: isci: use dma_set_mask_and_coherent scsi: initio: use dma_set_mask scsi: hptiop: use dma_set_mask scsi: hisi_sas: use dma_set_mask_and_coherent scsi: esas2r: use dma_set_mask_and_coherent scsi: dpt_i2o: use dma_set_mask scsi: bfa: use dma_set_mask_and_coherent scsi: arcmsr: use dma_set_mask scsi: pmcraid: use generic DMA API scsi: pmcraid: don't allocate a dma coherent buffer for sense data scsi: pmcraid: simplify pmcraid_cancel_all a bit scsi: qla2xxx: use lower_32_bits and upper_32_bits instead of reinventing them scsi: qla1280: properly handle 64-bit DMA scsi: qla1280: use lower_32_bits and upper_32_bits instead of reinventing them scsi: ips: properly handle 64-bit DMA scsi: ips: use lower_32_bits and upper_32_bits instead of reinventing them Colin Ian King (3): scsi: bfa: clean up a couple of indentation issues scsi: 3w-: fix indentation issue, add missing tab scsi: mpt3sas: fix spelling mistake "manufaucturing" -> "manufacturing" Dave Carroll (7): scsi: smartpqi: correct volume status scsi: smartpqi: do not offline disks for transient did no connect conditions scsi: smartpqi: wake up drives after os
Re: [PATCH 1/3] pinctrl: armada-37xx: Correct mpp definitions
Hi Marek,
On sam., déc. 22 2018, Marek Behun wrote:
> On Fri, 21 Dec 2018 18:32:57 +0100
> Gregory CLEMENT wrote:
>
>> +PIN_GRP_GPIO("pcie1", 3, 1, BIT(5), "pcie"),
>> +PIN_GRP_GPIO("pcie1_clkreq", 4, 1, BIT(9), "pcie"),
>
> If the pair is split to clkreq and reset, shouldn't the first be called
> pcie1_reset?
I considered this but chose to keep pcie1 in order to preserve backward
compatibility.
I agree that it is debatable, because without the fix the old device
tree can't work. However I find it better preserving the initial intent
of an existing device tree.
By talking about it, I think about an other option, keeping pcie1 name
to setup the pins 39 and 40 how it was documented. And introducing
pcie1_reset and pcie1_clkreq for new binding. however I don't know how
it could be handle by the pinctrl framework.
Gregory
> Marek
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
[GIT PULL] SELinux patches v4.21
Hi Linus, I already used my best holiday pull request lines in the audit pull request, so this one is going to be a bit more boring, sorry about that. To make up for this, we do have a birthday of sorts to celebrate: SELinux turns 18 years old this December. Perhaps not the most exciting thing in the world for most people, but I think it's safe to say that anyone reading this email doesn't exactly fall into the "most people" category. Back to business and the pull request itself. Ondrej has five patches in this pull request and I lump them into three categories: one patch to always allow submounts (using similar logic to elsewhere in the kernel), one to fix some issues with the SELinux policydb, and the others to cleanup and improve the SELinux sidtab. The other patches from Alexey and Petr and trivial fixes that are adequately described in their respective subject lines. This is generally a pretty standard set of patches, but there is one potential merge conflict with the mount rework in the vfs tree. If needed, the fixup is pretty small and documented in the linux-next post below; if you have any questions about the merge let us know. * https://lore.kernel.org/lkml/20181218144858.58d8d...@canb.auug.org.au With this last pull request of the year, I want to thank everyone who has contributed patches, testing, and reviews to the SELinux project this year, and the past 18 years. Like any good open source effort, SELinux is only as good as the community which supports it, and I'm very happy that we have the community we do - thank you all! -Paul -- The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20181224 for you to fetch changes up to ee1a84fdfeedfd7362e9a8a8f15fedc3482ade2d: selinux: overhaul sidtab to fix bug and improve performance (2018-12-05 16:12:32 -0500) selinux/stable-4.21 PR 20181224 Alexey Dobriyan (1): selinux: make "selinux_policycap_names[]" const char * Ondrej Mosnacek (5): selinux: policydb - fix byte order and alignment issues selinux: refactor sidtab conversion selinux: always allow mounting submounts selinux: use separate table for initial SID lookup selinux: overhaul sidtab to fix bug and improve performance Petr Vorel (1): Documentation: Update SELinux reference policy URL Documentation/admin-guide/LSM/SELinux.rst | 2 +- security/selinux/hooks.c | 2 +- security/selinux/include/security.h | 2 +- security/selinux/ss/mls.c | 24 +- security/selinux/ss/mls.h | 3 +- security/selinux/ss/policydb.c| 61 +++- security/selinux/ss/services.c| 222 +-- security/selinux/ss/services.h| 2 +- security/selinux/ss/sidtab.c | 609 ++- security/selinux/ss/sidtab.h | 96 +++-- 10 files changed, 626 insertions(+), 397 deletions(-) -- paul moore www.paul-moore.com
[PATCH] slimbus: Add a check on the return value of platform_device_add
In of_qcom_slim_ngd_register, the function platform_device_add() may fail. The fix returns the error value upstream in case of failure. Signed-off-by: Aditya Pakki --- drivers/slimbus/qcom-ngd-ctrl.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c index 1382a8df6c75..a2dffb2b4c88 100644 --- a/drivers/slimbus/qcom-ngd-ctrl.c +++ b/drivers/slimbus/qcom-ngd-ctrl.c @@ -1329,6 +1329,7 @@ static int of_qcom_slim_ngd_register(struct device *parent, struct qcom_slim_ngd *ngd; struct device_node *node; u32 id; + int ret; data = of_match_node(qcom_slim_ngd_dt_match, parent->of_node)->data; @@ -1348,7 +1349,10 @@ static int of_qcom_slim_ngd_register(struct device *parent, ctrl->ngd = ngd; platform_set_drvdata(ngd->pdev, ctrl); - platform_device_add(ngd->pdev); + ret = platform_device_add(ngd->pdev); + if (ret) + return ret; + ngd->base = ctrl->base + ngd->id * data->offset + (ngd->id - 1) * data->size; ctrl->ngd = ngd; -- 2.17.1
[PATCH v2] staging: wlan-ng: prism2fw.c: Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning"
This patch removes unnecessary out of memory warning
message from wlan-ng prism2fw.c file.
Signed-off-by: Prathamesh Deshpande
---
drivers/staging/wlan-ng/prism2fw.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2fw.c
b/drivers/staging/wlan-ng/prism2fw.c
index bb572b7..94800c0 100644
--- a/drivers/staging/wlan-ng/prism2fw.c
+++ b/drivers/staging/wlan-ng/prism2fw.c
@@ -556,10 +556,9 @@ static int mkimage(struct imgchunk *clist, unsigned int
*ccnt)
/* Allocate buffer space for chunks */
for (i = 0; i < *ccnt; i++) {
clist[i].data = kzalloc(clist[i].len, GFP_KERNEL);
- if (!clist[i].data) {
- pr_err("failed to allocate image space, exiting.\n");
+ if (!clist[i].data)
return 1;
- }
+
pr_debug("chunk[%d]: addr=0x%06x len=%d\n",
i, clist[i].addr, clist[i].len);
}
--
1.8.3.1
[PATCH v1 1/2] dt-binding: iio: add NPCM ADC documentation
Added device tree binding documentation for Nuvoton BMC
NPCM Analog-to-Digital Converter(ADC).
Signed-off-by: Tomer Maimon
---
.../bindings/iio/adc/nuvoton,npcm-adc.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt
b/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt
new file mode 100644
index ..6f0843d837cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt
@@ -0,0 +1,35 @@
+Nuvoton NPCM Analog to Digital Converter (ADC)
+
+The NPCM ADC is a 10-bit converter for eight channel inputs.
+
+Required properties:
+- compatible : "nuvoton,npcm750-adc" for the NPCM7XX BMC.
+- reg : specifies physical base address and size of the
registers.
+- interrupts : Contain the ADC interrupt with flags for falling edge.
+
+Optional properties:
+- clocks : phandle of ADC reference clock, in case the clock is
not
+ added the ADC will use the default ADC sample
rate.
+- vref-supply : The regulator supply ADC reference voltage, in case the
+ vref-supply is not added the ADC will use
internal voltage
+ reference.
+
+Required Node in the NPCM7xx BMC:
+An additional register is present in the NPCM7xx SOC which is
+assumed to be in the same device tree, with and marked as
+compatible with "nuvoton,npcm750-rst".
+
+Example:
+
+adc: adc@f000c000 {
+ compatible = "nuvoton,npcm750-adc";
+ reg = <0xf000c000 0x8>;
+ interrupts = ;
+ clocks = < NPCM7XX_CLK_ADC>;
+};
+
+rst: rst@f0801000 {
+ compatible = "nuvoton,npcm750-rst", "syscon",
+ "simple-mfd";
+ reg = <0xf0801000 0x6C>;
+};
--
2.14.1
[PATCH v1 2/2] iio: adc: add NPCM ADC driver
Add Nuvoton NPCM BMC Analog-to-Digital Converter(ADC) driver.
The NPCM ADC is a 10-bit converter for eight channel inputs.
Signed-off-by: Tomer Maimon
---
drivers/iio/adc/Kconfig| 10 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/npcm_adc.c | 336 +
3 files changed, 347 insertions(+)
create mode 100644 drivers/iio/adc/npcm_adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a52fea8749a9..63a4204c5673 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -555,6 +555,16 @@ config NAU7802
To compile this driver as a module, choose M here: the
module will be called nau7802.
+config NPCM_ADC
+ tristate "Nuvoton NPCM ADC driver"
+ depends on ARCH_NPCM || COMPILE_TEST
+ depends on HAS_IOMEM
+ help
+ Say yes here to build support for Nuvoton NPCM ADC.
+
+ This driver can also be built as a module. If so, the module
+ will be called npcm_adc.
+
config PALMAS_GPADC
tristate "TI Palmas General Purpose ADC"
depends on MFD_PALMAS
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a6e6a0b659e2..b0c3f3b73a5f 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
obj-$(CONFIG_MXS_LRADC_ADC) += mxs-lradc-adc.o
obj-$(CONFIG_NAU7802) += nau7802.o
+obj-$(CONFIG_NPCM_ADC) += npcm_adc.o
obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
obj-$(CONFIG_QCOM_SPMI_ADC5) += qcom-spmi-adc5.o
obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
diff --git a/drivers/iio/adc/npcm_adc.c b/drivers/iio/adc/npcm_adc.c
new file mode 100644
index ..4f7851472997
--- /dev/null
+++ b/drivers/iio/adc/npcm_adc.c
@@ -0,0 +1,336 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2016-2018 Nuvoton Technology corporation.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct npcm_adc {
+ u32 vref_mv;
+ bool int_status;
+ u32 adc_sample_hz;
+ struct device *dev;
+ void __iomem *regs;
+ struct clk *adc_clk;
+ wait_queue_head_t wq;
+ struct regulator *vref;
+ struct regmap *rst_regmap;
+};
+
+/* NPCM7xx reset module */
+#define IPSRST1_OFFSET 0x020
+#define IPSRST1_ADC_RSTBIT(27)
+
+/* ADC registers */
+#define NPCM_ADCCON 0x00
+#define NPCM_ADCDATA0x04
+
+/* ADCCON Register Bits */
+#define NPCM_ADCCON_ADC_INT_EN BIT(21)
+#define NPCM_ADCCON_REFSEL BIT(19)
+#define NPCM_ADCCON_ADC_INT_ST BIT(18)
+#define NPCM_ADCCON_ADC_EN BIT(17)
+#define NPCM_ADCCON_ADC_RSTBIT(16)
+#define NPCM_ADCCON_ADC_CONV BIT(13)
+
+#define NPCM_ADCCON_CH_MASKGENMASK(27, 24)
+#define NPCM_ADCCON_CH(x) ((x) << 24)
+#define NPCM_ADCCON_DIV_SHIFT 1
+#define NPCM_ADCCON_DIV_MASK GENMASK(8, 1)
+#define NPCM_ADC_DATA_MASK(x) ((x) & GENMASK(9, 0))
+
+#define NPCM_ADC_ENABLE(NPCM_ADCCON_ADC_EN |
NPCM_ADCCON_ADC_INT_EN)
+
+/* ADC General Definition */
+#define NPCM_RESOLUTION_BITS 10
+#define ADC_DEFAULT_SAMPLE_RATE1250
+#define INT_VREF_MV2000
+
+#define NPCM_ADC_CHAN(ch) {\
+ .type = IIO_VOLTAGE,\
+ .indexed = 1, \
+ .channel = ch, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+static const struct iio_chan_spec npcm_adc_iio_channels[] = {
+ NPCM_ADC_CHAN(0),
+ NPCM_ADC_CHAN(1),
+ NPCM_ADC_CHAN(2),
+ NPCM_ADC_CHAN(3),
+ NPCM_ADC_CHAN(4),
+ NPCM_ADC_CHAN(5),
+ NPCM_ADC_CHAN(6),
+ NPCM_ADC_CHAN(7),
+};
+
+static irqreturn_t npcm_adc_isr(int irq, void *data)
+{
+ u32 regtemp = 0;
+ struct iio_dev *indio_dev = data;
+ struct npcm_adc *info = iio_priv(indio_dev);
+
+ regtemp = ioread32(info->regs + NPCM_ADCCON);
+ if (regtemp & NPCM_ADCCON_ADC_INT_ST) {
+ iowrite32(regtemp, info->regs + NPCM_ADCCON);
+ wake_up_interruptible(>wq);
+ info->int_status = true;
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int npcm_adc_read(struct npcm_adc *info, int *val, u8 channel)
+{
+ int ret;
+ u32 regtemp = 0;
+
+ /* Select ADC channal */
+ regtemp = ioread32(info->regs + NPCM_ADCCON);
+ regtemp &= ~NPCM_ADCCON_CH_MASK;
+ iowrite32(regtemp | NPCM_ADCCON_CH(channel) |
+ NPCM_ADCCON_ADC_CONV, info->regs + NPCM_ADCCON);
+
+ info->int_status = false;
+ ret =
[PATCH v1 0/2] iio: adc: npcm: add NPCm ADC driver
This patch set adds Analog-to-Digital Converter (ADC) support for the Nuvoton NPCM Baseboard Management Controller (BMC). The NPCM ADC is a 10-bit converter for eight channel inputs. The NPCM ADC driver tested on NPCM750 evaluation board. Tomer Maimon (2): dt-binding: iio: add NPCM ADC documentation iio: adc: add NPCM ADC driver .../bindings/iio/adc/nuvoton,npcm-adc.txt | 35 +++ drivers/iio/adc/Kconfig| 10 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/npcm_adc.c | 336 + 4 files changed, 382 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt create mode 100644 drivers/iio/adc/npcm_adc.c -- 2.14.1
[PATCH] x86/intel-mid: Add pr_warn when platform_device_add() fails
platform_device_add() may fail in intel_scu_devices_create and
sfi_handle_ipc_dev. The fix checks for the return value in these cases
and displays the failed device.
Signed-off-by: Aditya Pakki
---
arch/x86/platform/intel-mid/sfi.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/x86/platform/intel-mid/sfi.c
b/arch/x86/platform/intel-mid/sfi.c
index 7be1e1fe9ae3..e69511bafec5 100644
--- a/arch/x86/platform/intel-mid/sfi.c
+++ b/arch/x86/platform/intel-mid/sfi.c
@@ -278,9 +278,13 @@ static void __init intel_scu_i2c_device_register(int bus,
void intel_scu_devices_create(void)
{
int i;
+ int ret;
- for (i = 0; i < ipc_next_dev; i++)
- platform_device_add(ipc_devs[i]);
+ for (i = 0; i < ipc_next_dev; i++) {
+ ret = platform_device_add(ipc_devs[i]);
+ if (ret)
+ pr_warn("can't add device %s\n", ipc_devs[i]);
+ }
for (i = 0; i < spi_next_dev; i++)
spi_register_board_info(spi_devs[i], 1);
@@ -330,6 +334,7 @@ static void __init sfi_handle_ipc_dev(struct
sfi_device_table_entry *pentry,
{
struct platform_device *pdev;
void *pdata = NULL;
+ int ret;
pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
pentry->name, pentry->irq);
@@ -360,8 +365,11 @@ static void __init sfi_handle_ipc_dev(struct
sfi_device_table_entry *pentry,
pdev->dev.platform_data = pdata;
if (dev->delay)
intel_scu_ipc_device_register(pdev);
- else
- platform_device_add(pdev);
+ else {
+ ret = platform_device_add(pdev);
+ if (ret)
+ pr_warn("can't add device %s\n", pdev);
+ }
}
static void __init sfi_handle_spi_dev(struct sfi_device_table_entry *pentry,
--
2.17.1
[PATCH] ipv6/route: Add a missing check on proc_dointvec
While flushing the cache via ipv6_sysctl_rtcache_flush(), the call
to proc_dointvec() may fail. The fix adds a check that returns the
error, on failure.
Signed-off-by: Aditya Pakki
---
net/ipv6/route.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 059f0531f7c1..5ccdaa27ec53 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -5053,12 +5053,16 @@ int ipv6_sysctl_rtcache_flush(struct ctl_table *ctl,
int write,
{
struct net *net;
int delay;
+ int ret;
if (!write)
return -EINVAL;
net = (struct net *)ctl->extra1;
delay = net->ipv6.sysctl.flush_delay;
- proc_dointvec(ctl, write, buffer, lenp, ppos);
+ ret = proc_dointvec(ctl, write, buffer, lenp, ppos);
+ if (ret)
+ return ret;
+
fib6_run_gc(delay <= 0 ? 0 : (unsigned long)delay, net, delay > 0);
return 0;
}
--
2.17.1
[GIT PULL] Audit patches for v4.21
Hi Linus, In the finest of holiday of traditions, I have a number of gifts to share today. While most of them are re-gifts from others, unlike the typical re-gift, these are things you will want in and around your tree; I promise. This pull request is perhaps a bit larger than our typical PR, but most of it comes from Jan's rework of audit's fanotify code; a very welcome improvement. We ran this through our normal regression tests, as well as some newly created stress tests and everything looks good. Richard added a few patches, mostly cleaning up a few things and and shortening some of the audit records that we send to userspace; a change the userspace folks are quite happy about. Finally YueHaibing and I kick in a few patches to simplify things a bit and make the code less prone to errors. Lastly, I want to say thanks one more time to everyone who has contributed patches, testing, and code reviews for the audit subsystem over the past year. The project is what it is due to your help and contributions - thank you. Thanks, -Paul -- The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git tags/audit-pr-20181224 for you to fetch changes up to d406db524c32ca35bd85cada28a547fff3115715: audit: remove duplicated include from audit.c (2018-12-14 12:09:30 -0500) audit/stable-4.21 PR 20181224 Jan Kara (14): audit_tree: Remove mark->lock locking audit: Fix possible spurious -ENOSPC error audit: Fix possible tagging failures audit: Embed key into chunk audit: Make hash table insertion safe against concurrent lookups audit: Factor out chunk replacement code audit: Remove pointless check in insert_hash() audit: Provide helper for dropping mark's chunk reference audit: Allocate fsnotify mark independently of chunk audit: Guarantee forward progress of chunk untagging audit: Drop all unused chunk nodes during deletion audit: Simplify locking around untag_chunk() audit: Replace chunk attached to mark instead of replacing mark audit: Use 'mark' name for fsnotify_mark variables Paul Moore (2): audit: minimize our use of audit_log_format() audit: use current whenever possible Richard Guy Briggs (5): audit: print empty EXECVE args audit: localize audit_log_session_info prototype audit: use session_info helper audit: remove WATCH and TREE config options audit: shorten PATH cap values when zero YueHaibing (1): audit: remove duplicated include from audit.c drivers/tty/tty_audit.c | 13 +- include/linux/audit.h| 8 +- init/Kconfig | 9 - kernel/Makefile | 4 +- kernel/audit.c | 62 ++--- kernel/audit.h | 10 +- kernel/audit_fsnotify.c | 6 +- kernel/audit_tree.c | 498 kernel/audit_watch.c | 6 +- kernel/auditsc.c | 150 ++-- security/integrity/ima/ima_api.c | 2 +- 11 files changed, 395 insertions(+), 373 deletions(-) -- paul moore www.paul-moore.com
Fwd: Re: [DNG] 2 months and no response from Eben Moglen - Yes you can rescind your grant. -- The CoC regime is a License violation - Additional restrictive terms
Original Message Subject: Re: [DNG] 2 months and no response from Eben Moglen - Yes you can rescind your grant. -- The CoC regime is a License violation - Additional restrictive terms Date: 2018-12-24 16:24 From: vnsnda...@memeware.net To: d...@lists.dyne.org Version 2 of the GPL forbids the incorporation of additional restrictive terms, relating to the distribution, modification, etc of the article licensed under the terms. Those that violate this section are declared, by operation of the terms, to have their grant automatically revoked. An additional term need-not be present in the same writing. Such terms simply need to be present to or made known to the taker(sub-licensee) by the distributor. They may be proffered in writing, orally, or implied in the course of doing business dealings. They simply must relate back or involve the article in question (the licensed code or product.) The proffering of additional restrictive terms is a violation of the text of the license grant in and of itself. Here we have a situation where an additional writing has been proffered. The additional writing promises both in it's own text and by implication consequences against those who violate the terms of this additional writing. The additional writing restricts those subject to it from expressing certain views publicly - promising retribution against those who do. No consideration is paid to those subject to the additional writing for their assent; it is simply imposed unilaterally against the subjects. The violators of the additional writing are promised: Additional, unwanted, public scrutiny (to which they were not subject to prior) Public ridicule. Loss of public standing. as-well as an implied loss of future income. These are the enforcement mechanisms of the additional writing to enforce its restrictions against those who publish derivative works of the kernel. The additional writing is activated when (with the prerequisite of being a derivative work of the linux kernel) the work of a rights-holder is incorporated into the kernel, when such a work is made known to the kernel-team to exist where any one person on this earth has seen fit to present it for inclusion, or by simple prior-inclusion into the kernel. Thus all current and past rights-holders who have code in, or have published for distribution, derivative works of the kernel are subject to the retributive promises made to them in the additional writing, drafted to restrict their actions and utterances. This is tantamount to an additional restrictive term regarding the modification and distribution of works under the linux kernel license grant. It is a violation of the license terms of the rights-holders past incorporated works in much the same way that GRSecurity's Contributor Access Agreement was and is. ___ Dng mailing list d...@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] 2 months and no response from Eben Moglen - Yes you can rescind your grant. -- The CoC regime is a License violation - Additional restrictive terms
Hendrik Boom, are you a lawyer? No? How about you shut your fucking mouth about things you have no clue of? Sound like a plan, ignorant lay person? Below is an explanation of just how it is a violation of the rights-holder's grant. The courts are not fooled by "clever" verbiage written up by laypersons such as yourself and such as the drafter of the CoC. They see things for what they are. Hendrik Boom wrote: Actually, no. It has no effect on what you can do with your copy of the Linux kernel. It just restricts your ability to participate fully in its development. But you can continue to use, modify, and distribute your copies as much as before, as provided by the license. -- hendrik Version 2 of the GPL forbids the incorporation of additional restrictive terms, relating to the distribution, modification, etc of the article licensed under the terms. Those that violate this section are declared, by operation of the terms, to have their grant automatically revoked. An additional term need-not be present in the same writing. Such terms simply need to be present to or made known to the taker(sub-licensee) by the distributor. They may be proffered in writing, orally, or implied in the course of doing business dealings. They simply must relate back or involve the article in question (the licensed code or product.) The proffering of additional restrictive terms is a violation of the text of the license grant in and of itself. Here we have a situation where an additional writing has been proffered. The additional writing promises both in it's own text and by implication consequences against those who violate the terms of this additional writing. The additional writing restricts those subject to it from expressing certain views publicly - promising retribution against those who do. No consideration is paid to those subject to the additional writing for their assent; it is simply imposed unilaterally against the subjects. The violators of the additional writing are promised: Additional, unwanted, public scrutiny (to which they were not subject to prior) Public ridicule. Loss of public standing. as-well as an implied loss of future income. These are the enforcement mechanisms of the additional writing to enforce its restrictions against those who publish derivative works of the kernel. The additional writing is activated when (with the prerequisite of being a derivative work of the linux kernel) the work of a rights-holder is incorporated into the kernel, when such a work is made known to the kernel-team to exist where any one person on this earth has seen fit to present it for inclusion, or by simple prior-inclusion into the kernel. Thus all current and past rights-holders who have code in, or have published for distribution, derivative works of the kernel are subject to the retributive promises made to them in the additional writing, drafted to restrict their actions and utterances. This is tantamount to an additional restrictive term regarding the modification and distribution of works under the linux kernel license grant. It is a violation of the license terms of the rights-holders past incorporated works in much the same way that GRSecurity's Contributor Access Agreement was and is.
Re: linux-next: Signed-off-by missing for commit in the cifs tree
Fixed and remerged to cifs-2.6.git for-next
On Mon, Dec 24, 2018 at 5:45 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Commit
>
> 87410161a381 ("cifs: check kzalloc return")
>
> is missing a Signed-off-by from its author.
>
> --
> Cheers,
> Stephen Rothwell
--
Thanks,
Steve
[PATCH] staging: wlan-ng: prism2fw.c: Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning"
This patch removes unnecessary out of memory warning
message from wlan-ng prism2fw.c file.
Signed-off-by: Prathamesh Deshpande
---
drivers/staging/wlan-ng/prism2fw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/prism2fw.c
b/drivers/staging/wlan-ng/prism2fw.c
index bb572b7..c040066 100644
--- a/drivers/staging/wlan-ng/prism2fw.c
+++ b/drivers/staging/wlan-ng/prism2fw.c
@@ -557,7 +557,6 @@ static int mkimage(struct imgchunk *clist, unsigned int
*ccnt)
for (i = 0; i < *ccnt; i++) {
clist[i].data = kzalloc(clist[i].len, GFP_KERNEL);
if (!clist[i].data) {
- pr_err("failed to allocate image space, exiting.\n");
return 1;
}
pr_debug("chunk[%d]: addr=0x%06x len=%d\n",
--
1.8.3.1
RE: [EXT] [PATCH v2] bnx2x: Fix NULL pointer dereference in bnx2x_del_all_vlans() on some hw
-Original Message-
From: Ivan Mironov [mailto:mironov.i...@gmail.com]
Sent: 24 December 2018 20:43
To: net...@vger.kernel.org
Cc: Ariel Elior ; Sudarsana Kalluru
; everest-linux...@cavium.com; David S. Miller
; linux-kernel@vger.kernel.org; Sudarsana Reddy Kalluru
; Ivan Mironov
Subject: [EXT] [PATCH v2] bnx2x: Fix NULL pointer dereference in
bnx2x_del_all_vlans() on some hw
External Email
--
This happened when I tried to boot normal Fedora 29 system with latest
available kernel (from fedora rawhide, plus some unrelated custom
patches):
BUG: unable to handle kernel NULL pointer dereference at
PGD 0 P4D 0
Oops: 0010 [#1] SMP PTI
CPU: 6 PID: 1422 Comm: libvirtd Tainted: G I
4.20.0-0.rc7.git3.hpsa2.1.fc29.x86_64 #1
Hardware name: HP ProLiant BL460c G6, BIOS I24 05/21/2018
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:a47ccdc9fbe0 EFLAGS: 00010246
RAX: RBX: 03e8 RCX: a47ccdc9fbf8
RDX: a47ccdc9fc00 RSI: 97d9ee7b01f8 RDI: 97d9f0150b80
RBP: 97d9f0150b80 R08: R09:
R10: R11: R12: 0003
R13: 97d9ef1e53e8 R14: 0009 R15: 97d9f0ac6730
FS: 7f4d224ef700() GS:97d9fa20()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: ffd6 CR3: 0011ece52006 CR4: 000206e0
Call Trace:
? bnx2x_chip_cleanup+0x195/0x610 [bnx2x]
? bnx2x_nic_unload+0x1e2/0x8f0 [bnx2x]
? bnx2x_reload_if_running+0x24/0x40 [bnx2x]
? bnx2x_set_features+0x79/0xa0 [bnx2x]
? __netdev_update_features+0x244/0x9e0
? netlink_broadcast_filtered+0x136/0x4b0
? netdev_update_features+0x22/0x60
? dev_disable_lro+0x1c/0xe0
? devinet_sysctl_forward+0x1c6/0x211
? proc_sys_call_handler+0xab/0x100
? __vfs_write+0x36/0x1a0
? rcu_read_lock_sched_held+0x79/0x80
? rcu_sync_lockdep_assert+0x2e/0x60
? __sb_start_write+0x14c/0x1b0
? vfs_write+0x159/0x1c0
? vfs_write+0xba/0x1c0
? ksys_write+0x52/0xc0
? do_syscall_64+0x60/0x1f0
? entry_SYSCALL_64_after_hwframe+0x49/0xbe
After some investigation I figured out that recently added cleanup code tries
to call VLAN filtering de-initialization function which exist only for newer
hardware. Corresponding function pointer is not set (== 0) for older hardware,
namely these chips:
#define CHIP_NUM_57710 0x164e
#define CHIP_NUM_57711 0x164f
#define CHIP_NUM_57711E 0x1650
And I have one of those in my test system:
Broadcom Inc. and subsidiaries NetXtreme II BCM57711E 10-Gigabit PCIe
[14e4:1650]
Function bnx2x_init_vlan_mac_fp_objs() from
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h decides whether to initialize
relevant pointers in bnx2x_sp_objs.vlan_obj or not.
This regression was introduced after v4.20-rc7, and still exists in v4.20
release.
Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload
sequence.")
Signed-off-by: Ivan Mironov
---
v2:
- As suggested by Sudarsana Reddy Kalluru, do not call bnx2x_del_all_vlans() at
all if (!CHIP_IS_E1x(bp)).
v1:
- Check for chip num instead of (vlan_obj->delete_all != 0).
v0:
- Patch introduced.
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index b164f705709d..3b5b47e98c73 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9360,10 +9360,16 @@ void bnx2x_chip_cleanup(struct bnx2x *bp, int
unload_mode, bool keep_link)
BNX2X_ERR("Failed to schedule DEL commands for UC MACs list:
%d\n",
rc);
- /* Remove all currently configured VLANs */
- rc = bnx2x_del_all_vlans(bp);
- if (rc < 0)
- BNX2X_ERR("Failed to delete all VLANs\n");
+ /* The whole *vlan_obj structure may be not initialized if VLAN
+* filtering offload is not supported by hardware. Currently this is
+* true for all hardware covered by CHIP_IS_E1x().
+*/
+ if (!CHIP_IS_E1x(bp)) {
+ /* Remove all currently configured VLANs */
+ rc = bnx2x_del_all_vlans(bp);
+ if (rc < 0)
+ BNX2X_ERR("Failed to delete all VLANs\n");
+ }
/* Disable LLH */
if (!CHIP_IS_E1(bp))
--
2.20.1
Thanks for the changes.
Acked-by: Sudarsana Kalluru
[PATCH] rts5208: Add a check on the status of ms_send_cmd
In mspro_stop_seq_mode(), ms_send_cmd() may fail. The patch attempts to detect a failure before flushing the registers via rtsx_write_register. Signed-off-by: Aditya Pakki --- drivers/staging/rts5208/ms.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c index f53adf15c685..04b588b8b376 100644 --- a/drivers/staging/rts5208/ms.c +++ b/drivers/staging/rts5208/ms.c @@ -2586,7 +2586,9 @@ void mspro_stop_seq_mode(struct rtsx_chip *chip) ms_card->seq_mode = 0; ms_card->total_sec_cnt = 0; - ms_send_cmd(chip, PRO_STOP, WAIT_INT); + retval = ms_send_cmd(chip, PRO_STOP, WAIT_INT); + if (retval != STATUS_SUCCESS) + return; rtsx_write_register(chip, RBCTL, RB_FLUSH, RB_FLUSH); } -- 2.17.1
general protection fault in transparent_hugepage_enabled
Hello, syzbot found the following crash on: HEAD commit:6a1d293238c1 Add linux-next specific files for 20181224 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=149a2add40 kernel config: https://syzkaller.appspot.com/x/.config?x=c190b602a5d2d731 dashboard link: https://syzkaller.appspot.com/bug?extid=a5fea9200aefd1cf4818 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1798bfb740 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f4dc5740 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a5fea9200aefd1cf4...@syzkaller.appspotmail.com sshd (6016) used greatest stack depth: 15720 bytes left kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 6032 Comm: syz-executor045 Not tainted 4.20.0-rc7-next-20181224 #187 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:transparent_hugepage_enabled+0x8c/0x5e0 mm/huge_memory.c:69 Code: 80 3c 02 00 0f 85 ae 04 00 00 4c 8b a3 a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 b8 01 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 91 04 00 00 49 8b bc 24 b8 01 00 00 e8 2d 70 e6 RSP: 0018:8881c2237138 EFLAGS: 00010202 RAX: dc00 RBX: 8881c2bdbc60 RCX: RDX: 0037 RSI: 81c8fa1a RDI: 01b8 RBP: 8881c2237160 R08: ed10383b25ed R09: ed10383b25ec R10: ed10383b25ec R11: 8881c1d92f63 R12: R13: 8881c2bdbd00 R14: dc00 R15: 0f5e FS: 01a48880() GS:8881dad0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 20b58000 CR3: 0001c221 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: show_smap+0x167/0x580 fs/proc/task_mmu.c:805 traverse+0x344/0x7b0 fs/seq_file.c:113 seq_read+0xc76/0x1150 fs/seq_file.c:188 do_loop_readv_writev fs/read_write.c:700 [inline] do_iter_read+0x4bc/0x670 fs/read_write.c:924 vfs_readv+0x175/0x1c0 fs/read_write.c:986 kernel_readv fs/splice.c:362 [inline] default_file_splice_read+0x539/0xb20 fs/splice.c:417 do_splice_to+0x12e/0x190 fs/splice.c:880 splice_direct_to_actor+0x31c/0x9d0 fs/splice.c:957 do_splice_direct+0x2d4/0x420 fs/splice.c:1066 do_sendfile+0x62a/0xe50 fs/read_write.c:1439 __do_sys_sendfile64 fs/read_write.c:1494 [inline] __se_sys_sendfile64 fs/read_write.c:1486 [inline] __x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1486 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x440089 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 14 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff3d710a18 EFLAGS: 0213 ORIG_RAX: 0028 RAX: ffda RBX: 7fff3d710a20 RCX: 00440089 RDX: 20b58000 RSI: 0003 RDI: 0003 RBP: 006ca018 R08: 0010 R09: 65732f636f72702f R10: R11: 0213 R12: 00401970 R13: 00401a00 R14: R15: Modules linked in: ---[ end trace faf026efd8795e93 ]--- RIP: 0010:transparent_hugepage_enabled+0x8c/0x5e0 mm/huge_memory.c:69 Code: 80 3c 02 00 0f 85 ae 04 00 00 4c 8b a3 a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 b8 01 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 91 04 00 00 49 8b bc 24 b8 01 00 00 e8 2d 70 e6 RSP: 0018:8881c2237138 EFLAGS: 00010202 RAX: dc00 RBX: 8881c2bdbc60 RCX: RDX: 0037 RSI: 81c8fa1a RDI: 01b8 RBP: 8881c2237160 R08: ed10383b25ed R09: ed10383b25ec R10: ed10383b25ec R11: 8881c1d92f63 R12: R13: 8881c2bdbd00 R14: dc00 R15: 0f5e FS: 01a48880() GS:8881dad0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 20b58000 CR3: 0001c221 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] Revert "serial: 8250: Fix clearing FIFOs in RS485 mode again"
Hi Marek,
On Fri, Dec 21, 2018 at 11:02:03PM +0100, Marek Vasut wrote:
> >> I shared the entire testcase, which now fails on AM335x due to this
> >> revert. Is there any progress on a proper fix from your side which does
> >> not break the AM335x ?
> >
> > No.
> >
> > Let's be clear - I didn't break your AM335x system, your broken patch
> > says that Daniel did with a commit applied back in v4.10. As such I
> > don't consider it my responsibility to fix your problem at all, I don't
> > have any access to the hardware anyway & I won't be buying hardware to
> > fix a bug for you.
> >
> > Despite all that I did write a patch which I expect would have solved
> > the problem for both of us, which is linked *twice* in the quoted emails
> > above & which as far as I can tell you *still* have not tested. I can
> > only surmise that you're trying deliberately to be annoying at this
> > point.
> >
> > If you want to try the patch I already wrote, and confirm whether it
> > actually works for you, then let's talk. Otherwise we're done here.
>
> Understood. However I did test your patch, but it was generating
> spurious IRQs and overruns (ttyS ttyS2: 91 input overrun(s)) on the
> AM335x, so that's not a proper solution.
OK, thanks for testing, and let's figure out what's going on. Since the
revert is in now I'd suggest starting from there - ie. approximately
from the code we've had since v4.10.
> I even brought the CI20 V2 I have back to life (yes, I bought one). The
> patch Ezequiel posted did fix the problem on the CI20, and did not break
> the AM335x, so I'd prefer if it was revisited instead of a heavy-handed
> revert.
As I described in an earlier email & on IRC, Ezequiel's one-liner does
not address all of the problems listed in my revert's commit message.
But again, since the revert is now in I suggest starting from there.
As neither a maintainer or significant contributor to
drivers/tty/serial, nor the author of the patch applied in v4.10 which
you say broke AM335x, nor someone with access to the affected hardware,
I'm probably not the best placed person to help you here - all I can do
is offer general debug suggestions. With that in mind, here are some
questions & ideas I have:
1) Your message for commit f6aa5beb45be ("serial: 8250: Fix clearing
FIFOs in RS485 mode again") suggests that the problem you're seeing
is specific to the __do_stop_tx_rs485() path. Does changing only
__do_stop_tx_rs485() to clear the FIFOs without disabling them,
without modifying other users of serial8250_clear_fifos(), fix your
problem? ie. does the following work?
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index f776b3eafb96..18d2a1a93f03 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1458,17 +1458,21 @@ static void serial8250_stop_rx(struct uart_port *port)
}
static void __do_stop_tx_rs485(struct uart_8250_port *p)
{
+ unsigned char fcr;
+
serial8250_em485_rts_after_send(p);
/*
* Empty the RX FIFO, we are not interested in anything
* received during the half-duplex transmission.
* Enable previously disabled RX interrupts.
*/
if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
- serial8250_clear_fifos(p);
+ fcr = serial_port_in(>port, UART_FCR);
+ serial_port_out(>port, UART_FCR,
+ fcr | UART_FCR_CLEAR_RCVR |
UART_FCR_CLEAR_XMIT);
p->ier |= UART_IER_RLSI | UART_IER_RDI;
serial_port_out(>port, UART_IER, p->ier);
}
Based on the comment above maybe leaving UART_FCR_CLEAR_XMIT out of
that might make sense too..?
Having __do_stop_tx_rs485() not share the FIFO clearing code with
other callers may make sense given that so far as I can see
__do_stop_tx_rs485() runs whilst the port is in use & other callers
of serial8250_clear_fifos() do not.
2) In an earlier email you said "The problem the original patch fixed
was that too many bits were cleared in the FCR on OMAP3/AM335x".
Could you clarify which bits we're talking about? From the AM335x
reference manual I can only see the DMA_MODE bit & the
[RT]X_FIFO_TRIG fields. Do you know which are problematic & why? In
your commit message you mention the AM335x UART swallowing &
retransmitting bytes - which field changing causes that?
> And I'd prefer to keep this thread alive, since I am still convinced
> that the FIFO handling code is wrong. Moreover, considering the UME bit
> on JZ4780 in FCR, the original code should confuse the UART on the
> JZ4780 too, although this might be hidden by some other surrounding code
> specific to the 8250 core on the JZ4780.
For completeness, as I said in an earlier email in the thread and as
we've since discussed on IRC, this is incorrect because
ingenic_uart_serial_out() unconditionally sets the
Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor.
Bradley M. Kuhn: The SFConservancy's new explanation was refuted 5 hours after it was published: Yes they can, greg. The GPL v2, is a bare license. It is not a contract. It lacks consideration between the licensee and the grantor. (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen to bestow a benefit upon them where they suffer no detriment and you, in fact, gain no bargained-for benefit) As a bare license, (read: property license), the standard rules regarding the alienation of property apply. Therein: a gratuitous license is revocable at the will of the grantor. The licensee then may ATTEMPT, as an affirmative defense against your as-of-right action to claim promissory estoppel in state court, and "keep you to your word". However you made no such promise disclaiming your right to rescind the license. Remeber: There is no utterance disclaiming this right within the GPL version 2. Linus, furthermore, has chosen both to exclude the "or any later version" codicil, to reject the GPL version 3, AND to publicly savage GPL version 3 (he surely has his reasons, perhaps this is one of them, left unstated). (GPLv3 which has such promises listed (not to say that they would be effective against the grantor, but it is an attempt at the least)). The Software Freedom Conservancy has attempted to mis-construe clause 4 of the GPL version 2 as a "no-revocation by grantor" clause. However, reading said clause, using plain construction, leads a reasonable person to understand that said clause is speaking specifically about the situation where an upstream licensee loses their permission under the terms due to a violation of the terms; in that case the down-stream licensee does not in-turn also lose their permission under the terms. Additionally, clause 0 makes it crystal clear that "You" is defined as the licensee, not the grantor. Another issue the SFConservancy's public service announcement chooses to ignore. Thirdly, the SFConservancy banks on the ignorance of both the public and the developers regarding property alienation. A license does not impinge the rights of the party granting the license in a quid-pro-quo manner vis a vis the licensee's taking. A license merely grants permission, extended from the grantor, to the licensee, regarding the article of property that is being impinged. A license is NOT a full nor is it a permanent alienation of the article(property) in question. The impinged property, being under a non bargained-for temporary grant, can be taken back into the sole dominion of the owner - at his election to do so. Now as to the 9th circuit appellate court's decision in Jacobsen v. Katzer . While the court waxes eloquently about opensource licenses, even mentioning the word "consideration" in it's long dicta, when it comes time to make the binding decision the court found that the lower (district) court was in _ERROR_ regarding the application of contract-law principals to the Artistic License, regarding the case, and instructed the lower court to instead construe said license as a Copyright License. The SFConservancy, and Bruce Perens have chosen to: 1) Rely on the dicta. (non-binding - "some things could be contracts - opensource is great") 2) Ignore the actual ruling. (Binding - Copyright License - Not Contract) 3) Ignore that this case was about the AL, not the GPLv2 4) Ignore the existence of different jurisdictions. (Why file in the roll-the-dice 9th district if you can file in a district that has personal-juristicion over the defendant and is much more consistent in it's rulings?) 5) Ignore all established law regard property licensing, contract formation, meeting of the minds, what consideration is etc. Which is not surprising considering the desire of people like Bruce Perens is to rob MEN of EVERY benefit of their Labour and every speck of happiness in life and to transfer those benefits to WOMEN and those who support women. (This is why people who are like Bruce Perens, the SFConservancy menbers, and the CoC supporters, banned men from taking female children as brides: in contrivance to the law of YHWH (Devarim chapter 22 - - verse 28 (na'ar (LXX: padia)), and continue to uphold that ban world-wide, and seek to destroy ALL cultures that do no bend to their will who are not idolators of Women) Look, you may love your users, you may love the people who edit your code in their home or office; but the fact of the matter is... They have done nothing for you, they have promised nothing to you. They CANNOT hold YOU. You have the right to rescind at any time, and remove your work from any future versions of Linux. And you might consider doing so if YOU are done harm. Don't let the insatiable, never-satisfied, public fool you into thinking otherwise. And, yes, I am a lawyer. And, no, unlike the SFConservancy, I did not have to call upon outside counsel to analyze the fact
Re: [PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
Hi, On Tue, Dec 18, 2018 at 02:50:58PM +0100, Xue Liu wrote: > Hello Andreas, > > On Mon, 17 Dec 2018 at 15:19, Andreas Färber wrote: > > > > Hello Xue Liu, > > > > Am 17.12.18 um 09:50 schrieb Xue Liu: > > > I have a question about the architecture of your module. AFAIK LoRaWAN > > > is already the MAC Layer above the LoRa technology. Why do you want to > > > make a new layer called "maclorawan" ? > > > > I had asked Jian-Hong to separate between his soft-MAC implementation > > and the common bits needed to drive hard-MAC implementations found on > > several of the hardware modules made available to me. > > > As a reference Linux 802.11 uses cfg80211 to talk with hard-MAC devices. > We may also use the name “cfglora” for hard-MAC implementation. > There exists also a cfg802154. :-) Note that cfg80211 is also for providing a backwardscompatibility to the wireless ioctl() interface. In theory it's simple: netlink API -> SoftMAC (macFOOBAR layer) -> cfgFOOBAR implementation -> driver layer \-> HardMAC (driver layer) -> cfgFOOBAR implementation The "difficult" part is providing one userspace interface for both either SoftMAC layer and all HardMAC drivers. There both maintainers need to be synchronized. As a side note I want to mention that the 802.15.4 subsystem supports currently a HardMAC transceiver in the SoftMAC layer. We don't have quite HardMAC support yet but are somehow prepared according the wireless architecture above. The people who did that didn't wanted to investigate time to implement a whole HardMAC layer, as I told them when we support more in the SoftMAC layer it will break their transceiver... so they was fine with that as warning it seems. :-) - Alex
[PATCH] media/lgdt3306a: Add a missing return value check.
In lgdt3306a.c, lgdt3306a_read_signal_strength() can fail while reading the registers via lgdt3306a_read_reg(). The function can return an error from i2c_transfer(). The fix checks the return value for this failure. Signed-off-by: Aditya Pakki --- drivers/media/dvb-frontends/lgdt3306a.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/lgdt3306a.c b/drivers/media/dvb-frontends/lgdt3306a.c index 0e1f5daaf20c..b79f652d05e1 100644 --- a/drivers/media/dvb-frontends/lgdt3306a.c +++ b/drivers/media/dvb-frontends/lgdt3306a.c @@ -1685,7 +1685,10 @@ static int lgdt3306a_read_signal_strength(struct dvb_frontend *fe, case QAM_256: case QAM_AUTO: /* need to know actual modulation to set proper SNR baseline */ - lgdt3306a_read_reg(state, 0x00a6, ); + ret = lgdt3306a_read_reg(state, 0x00a6, ); + if (lg_chkerr(ret)) + goto fail; + if(val & 0x04) ref_snr = 2800; /* QAM-256 28dB */ else -- 2.17.1
Re: [PATCH v5 2/6] media: sun6i: Add mod_rate quirk
On Fri, Dec 21, 2018 at 6:30 PM Maxime Ripard wrote:
>
> On Thu, Dec 20, 2018 at 06:24:34PM +0530, Jagan Teki wrote:
> > Unfortunately default CSI_SCLK rate cannot work properly to
> > drive the connected sensor interface, particularly on few
> > Allwinner SoC's like A64.
> >
> > So, add mod_rate quirk via driver data so-that the respective
> > SoC's which require to alter the default mod clock rate can assign
> > the operating clock rate.
> >
> > Signed-off-by: Jagan Teki
> > ---
> > .../platform/sunxi/sun6i-csi/sun6i_csi.c | 34 +++
> > 1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > index ee882b66a5ea..fe002beae09c 100644
> > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -28,8 +29,13 @@
> >
> > #define MODULE_NAME "sun6i-csi"
> >
> > +struct sun6i_csi_variant {
> > + unsigned long mod_rate;
> > +};
> > +
> > struct sun6i_csi_dev {
> > struct sun6i_csicsi;
> > + const struct sun6i_csi_variant *variant;
> > struct device *dev;
> >
> > struct regmap *regmap;
> > @@ -822,33 +828,43 @@ static int sun6i_csi_resource_request(struct
> > sun6i_csi_dev *sdev,
> > return PTR_ERR(sdev->clk_mod);
> > }
> >
> > + if (sdev->variant->mod_rate)
> > + clk_set_rate_exclusive(sdev->clk_mod,
> > sdev->variant->mod_rate);
> > +
>
> It still doesn't make any sense to do it in the probe function...
I'm not sure we discussed about the context wrt probe, we discussed
about exclusive put clock. Since clocks were enabling in set_power and
clock rate can be set during probe in single time instead of setting
it in set_power for every power enablement. anything wrong with that.
>
> We discussed this in the previous iteration already.
>
> What we didn't discuss is the variant function that you introduce,
> while the previous approach was enough.
We discussed about clk_rate_exclusive_put, and that even handle it in
.remove right? so I have variant to handle it in sun6i_csi_remove.
2 months and no response from Eben Moglen - Yes you can rescind your grant.
It has been 2 months. Eben Moglen has published no research. Because there is nothing more to say: The GPLv2, as used by linux, is a bare license. It can be rescinded at the will of the grantor. The regime that the FSF used, vis-a-vis the GPLv2, is essential: copyright transfers to a central repository entity that is sure not to rescind. Linus chose not to adopt this regime. He benefited by greatly increased developer contribution. The price for that windfall was and is the retention of their traditional property rights by the property holders. They can rescind at will. They made no promise nor utterance to the contrary that can be relied upon. They were paid no consideration. There was no meeting of the minds. Additionally the CoC regime itself is a license terms violation, being an additional restrictive term, as explained in the other analysis. (Similar to the GRSecurity license violation) On 2018-10-26 18:31, Eben Moglen wrote: On Friday, 26 October 2018, visionsofal...@redchan.it wrote: You are conflating case law dealing with commercial software and non-gratuitous licenses with the present situation, which would likely be a case of first-impression in nearly any jurisdiction. I think the best procedure would be for me to publish my analysis and for you then to tell me what is wrong with it. What you say here sounds like what a lawyer might say, but isn't. I have been teaching this stuff for about thirty years, so if I am conflating or confusing anything I will be grateful for help in seeing my mistake. The rule for gratuitous licenses is that they are revocable at the will of the grantor. That's not actually "the rule." It sounds like it might be the rule, but it so happens that it's not. When I have given the explanation as I have learned, taught and depended on it, you will be able to show me what I am wrong about. Raymond Nimmer (God rest his soul) was in agreement on this point, vis-a-vis the GPL and similar licenses. You have your Nimmers confused. The primary author of the treatise Nimmer on Copyright (a book about the law, not in itself an authority) was Melville Nimmer. The treatise is continued by his son, David, a fine lawyer with whom I do from time to time politely disagree about something. Ray Nimmer is quite another person. Eben
Reason for RedHat purchase 30 pct over market cap
Redhat has achieved "governance" over the Linux(TM), via systemd and the Code of Conduct. You, contributors, are now treated as employees. They are confident that you will not assert your property rights, since you attack those who do (See: Netfiter saga), and take it as an honour to sign documents pledging that you will not assert your property rights (prepared for you by your now-masters). They know that you are psychologically bound to behave as hirelings - servants, and not as property owners. Thus they can rest easy knowing the ground is, though made of sand, not in seeming danger of a tempest. Because of you. Because of your history of supplication. Your enuich-like nature. A nice example is Bradly Kuhn's recent blog posts 1) Excoriating RMS and 2) showing how he himself is submissive to a woman he hired. He's even angry that others still treat him with respect rather than transferring all the good will to the female figurehead everyone is supposed to now respect (for what reason? No, being an actual programmer is not required: sufficent is being a member of the "better" species that rules over the males under the anglo-american system that Bradly Kuhn and his kind uphold ) If I were them I would never donate another cent to the SFConservancy, and I would seek a claw-back of the funds that I did donate for improper use (yes this is possible under both California and New York law). Especially since they seem to have no in-house lawyers what-so-ever (so what is their purpose?). We are supposed to be proud that his mind is as innocent as his visage (perhaps why he had to hire outside counsel to give him an incorrect and abundantly couched opinion) [1] http://ebb.org/bkuhn/blog/2018/11/22/gnu-kind-communication-guidelines.html [2] http://ebb.org/bkuhn/blog/2018/06/21/everyday-sexism.html
INFO: rcu detected stall in snd_pcm_oss_read
Hello,
syzbot found the following crash on:
HEAD commit:3c730b1041ae Merge branch 'fixes' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16a6cf1b40
kernel config: https://syzkaller.appspot.com/x/.config?x=861a3573f4e78ba1
dashboard link: https://syzkaller.appspot.com/bug?extid=fbe0496f92a0ce7b786c
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=131fdcdd40
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1647bf7d40
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+fbe0496f92a0ce7b7...@syzkaller.appspotmail.com
hrtimer: interrupt took 35234 ns
audit: type=1400 audit(1545621421.464:37): avc: denied { map } for
pid=6182 comm="sh" path="/bin/dash" dev="sda1" ino=1473
scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=system_u:object_r:file_t:s0 tclass=file permissive=1
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 0-: (13423 ticks this GP) idle=6c6/1/0x4002
softirq=7663/7665 fqs=5214
rcu: (t=10500 jiffies g=5229 q=6)
NMI backtrace for cpu 0
CPU: 0 PID: 6180 Comm: syz-executor053 Not tainted 4.20.0-rc7+ #165
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113
nmi_cpu_backtrace.cold.4+0x63/0xa2 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x1c2/0x22c lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
rcu_dump_cpu_stacks+0x16f/0x1bc kernel/rcu/tree.c:1195
print_cpu_stall.cold.65+0x1f3/0x3c6 kernel/rcu/tree.c:1334
check_cpu_stall kernel/rcu/tree.c:1408 [inline]
rcu_pending kernel/rcu/tree.c:2961 [inline]
rcu_check_callbacks+0xac1/0x1410 kernel/rcu/tree.c:2506
update_process_times+0x2d/0x70 kernel/time/timer.c:1636
tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
__run_hrtimer kernel/time/hrtimer.c:1398 [inline]
__hrtimer_run_queues+0x41c/0x10d0 kernel/time/hrtimer.c:1460
hrtimer_interrupt+0x313/0x780 kernel/time/hrtimer.c:1518
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1034 [inline]
smp_apic_timer_interrupt+0x1a1/0x760 arch/x86/kernel/apic/apic.c:1059
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
RIP: 0010:__raw_read_unlock_irq include/linux/rwlock_api_smp.h:244 [inline]
RIP: 0010:_raw_read_unlock_irq+0x56/0x80 kernel/locking/spinlock.c:264
Code: 52 89 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00
75 32 48 83 3d 33 94 7a 01 00 74 1f fb 66 0f 1f 44 00 00 01 00 00 00
e8 d0 c2 7d f9 65 8b 05 69 80 2a 78 85 c0 74 05 5b
RSP: 0018:8881be89f660 EFLAGS: 0282 ORIG_RAX: ff13
RAX: dc00 RBX: 89e89e60 RCX: 111039b689cc
RDX: 112a4030 RSI: RDI: 89520180
RBP: 8881be89f668 R08: 8881cdb44e60 R09: 0006
R10: R11: 8881cdb445c0 R12: 0001
R13: R14: R15: 8881be89f828
__snd_pcm_stream_unlock_mode+0x125/0x150 sound/core/pcm_native.c:145
snd_pcm_stream_unlock_irq sound/core/pcm_native.c:202 [inline]
snd_pcm_delay+0x234/0x380 sound/core/pcm_native.c:2698
snd_pcm_kernel_ioctl+0x1e0/0x220 sound/core/pcm_native.c:2998
snd_pcm_oss_capture_position_fixup+0x1a1/0x250
sound/core/oss/pcm_oss.c:1202
snd_pcm_oss_read3+0x181/0x410 sound/core/oss/pcm_oss.c:1271
io_capture_transfer+0x27d/0x310 sound/core/oss/io.c:73
snd_pcm_plug_read_transfer+0x1d7/0x3b0 sound/core/oss/pcm_plugin.c:651
snd_pcm_oss_read2+0x221/0x450 sound/core/oss/pcm_oss.c:1474
snd_pcm_oss_read1 sound/core/oss/pcm_oss.c:1512 [inline]
snd_pcm_oss_read+0x4e4/0x820 sound/core/oss/pcm_oss.c:2752
__vfs_read+0x117/0x9b0 fs/read_write.c:416
vfs_read+0x17f/0x3c0 fs/read_write.c:452
ksys_read+0x101/0x260 fs/read_write.c:578
__do_sys_read fs/read_write.c:588 [inline]
__se_sys_read fs/read_write.c:586 [inline]
__x64_sys_read+0x73/0xb0 fs/read_write.c:586
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x443ef9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 7b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fffd155a428 EFLAGS: 0217 ORIG_RAX:
RAX: ffda RBX: 004002e0 RCX: 00443ef9
RDX: 0008 RSI: 2180 RDI: 0003
RBP: 006ce018 R08: 004002e0 R09: 004002e0
R10: 004002e0 R11: 0217 R12: 00401c00
R13: 00401c90 R14: R15:
sched: RT
general protection fault in xfrm_policy_insert_list
Hello, syzbot found the following crash on: HEAD commit:ce28bb445388 Merge git://git.kernel.org/pub/scm/linux/kern.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=17803ac340 kernel config: https://syzkaller.appspot.com/x/.config?x=67a2081147a23142 dashboard link: https://syzkaller.appspot.com/bug?extid=e879931aaae5c1abca56 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+e879931aaae5c1abc...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 6146 Comm: syz-executor5 Not tainted 4.20.0-rc7+ #358 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:xfrm_policy_insert_list+0x174/0x1020 net/xfrm/xfrm_policy.c:1532 kobject: 'loop0' (8b3a9204): kobject_uevent_env Code: ff ff ff 48 c1 e8 03 4c 01 e0 48 89 85 20 ff ff ff e8 40 d6 b3 fa 48 8d bb 19 02 00 00 48 89 f8 48 89 fa 48 c1 e8 03 83 e2 07 <42> 0f b6 04 20 38 d0 7f 08 84 c0 0f 85 f5 0b 00 00 44 0f b6 ab 19 RSP: 0018:88819772f098 EFLAGS: 00010202 RAX: 002580bf RBX: 012c03e0 RCX: c9000fe54000 RDX: 0001 RSI: 86cae280 RDI: 012c05f9 kobject: 'loop0' (8b3a9204): fill_kobj_path: path = '/devices/virtual/block/loop0' RBP: 88819772f1c0 R08: 8881d32c2480 R09: 111037615f21 R10: 0003 R11: 888192b2a600 R12: dc00 R13: R14: 8bc53300 R15: FS: 7fb18f7ca700() GS:8881daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 kobject: 'loop3' (bef5b68b): kobject_uevent_env CR2: 004d9300 CR3: 000180ff1000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: kobject: 'loop3' (bef5b68b): fill_kobj_path: path = '/devices/virtual/block/loop3' xfrm_policy_inexact_insert+0x166/0xee0 net/xfrm/xfrm_policy.c:1195 kobject: 'loop0' (8b3a9204): kobject_uevent_env kobject: 'loop0' (8b3a9204): fill_kobj_path: path = '/devices/virtual/block/loop0' xfrm_policy_insert+0x639/0x850 net/xfrm/xfrm_policy.c:1570 xfrm_add_policy+0x2a0/0x6f0 net/xfrm/xfrm_user.c:1657 kobject: 'loop2' (0496a7a1): kobject_uevent_env xfrm_user_rcv_msg+0x44c/0x8e0 net/xfrm/xfrm_user.c:2663 kobject: 'loop2' (0496a7a1): fill_kobj_path: path = '/devices/virtual/block/loop2' netlink_rcv_skb+0x16c/0x430 net/netlink/af_netlink.c:2477 xfrm_netlink_rcv+0x6f/0x90 net/xfrm/xfrm_user.c:2671 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] netlink_unicast+0x59f/0x750 net/netlink/af_netlink.c:1336 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1917 kobject: 'loop2' (0496a7a1): kobject_uevent_env sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116 kobject: 'loop2' (0496a7a1): fill_kobj_path: path = '/devices/virtual/block/loop2' kobject: 'loop0' (8b3a9204): kobject_uevent_env kobject: 'loop0' (8b3a9204): fill_kobj_path: path = '/devices/virtual/block/loop0' __sys_sendmsg+0x11d/0x280 net/socket.c:2154 kobject: 'loop2' (0496a7a1): kobject_uevent_env __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg net/socket.c:2161 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 kobject: 'loop2' (0496a7a1): fill_kobj_path: path = '/devices/virtual/block/loop2' kobject: 'loop0' (8b3a9204): kobject_uevent_env kobject: 'loop0' (8b3a9204): fill_kobj_path: path = '/devices/virtual/block/loop0' entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457669 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fb18f7c9c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00457669 kobject: 'loop2' (0496a7a1): kobject_uevent_env RDX: RSI: 2014f000 RDI: 0003 RBP: 0072bf00 R08: R09: R10: R11: 0246 R12: 7fb18f7ca6d4 R13: 004c44d8 R14: 004d74e8 R15: Modules linked in: ---[ end trace 818a477ec48fd0a4 ]--- kobject: 'loop2' (0496a7a1): fill_kobj_path: path = '/devices/virtual/block/loop2' RIP: 0010:xfrm_policy_insert_list+0x174/0x1020 net/xfrm/xfrm_policy.c:1532
Re: [PATCH 3/3] firmware: rewrite Makefile
On Fri, Dec 21, 2018 at 5:43 PM Masahiro Yamada
wrote:
>
> Clean up the Makefile. Equivalent *.gen.S files are produced.
>
> - Use filechk to remove ugly wordsize_deps
>
> - Get FWNAME, FWSTR, ASM_WORD, ASM_ALIGN, and PROGBITS out of the
>recipe for readability
>
> - Move mkdir into the recipe
>
> - Clean up generated directories by 'make clean'
>
> Signed-off-by: Masahiro Yamada
> ---
>
> For this patch to work correctly,
> the following prerequisite is necessary:
>
> https://patchwork.kernel.org/patch/10707461/
>
> So, I will queue this series to kbuild tree.
>
> BTW, my next plan is to move firmware/ to
> more relevant place, for example,
> drivers/base/firmware_loader/builtin.
>
>
> firmware/Makefile | 89
> ++-
> 1 file changed, 35 insertions(+), 54 deletions(-)
>
> diff --git a/firmware/Makefile b/firmware/Makefile
> index 2964138..18d1c84 100644
> --- a/firmware/Makefile
> +++ b/firmware/Makefile
> @@ -1,61 +1,42 @@
> # SPDX-License-Identifier: GPL-2.0
> -#
> -# kbuild file for firmware/
> -#
>
> -# Create $(fwabs) from $(CONFIG_EXTRA_FIRMWARE_DIR) -- if it doesn't have a
> +# Create $(fwdir) from $(CONFIG_EXTRA_FIRMWARE_DIR) -- if it doesn't have a
> # leading /, it's relative to $(srctree).
> fwdir := $(subst $(quote),,$(CONFIG_EXTRA_FIRMWARE_DIR))
> -fwabs := $(addprefix $(srctree)/,$(filter-out /%,$(fwdir)))$(filter
> /%,$(fwdir))
> -
> -fw-external-y := $(subst $(quote),,$(CONFIG_EXTRA_FIRMWARE))
> -
> -quiet_cmd_fwbin = MK_FW $@
> - cmd_fwbin = FWNAME="$(patsubst firmware/%.gen.S,%,$@)"; \
> - FWSTR="$(subst /,_,$(subst .,_,$(subst -,_,$(patsubst \
> - firmware/%.gen.S,%,$@"; \
> - ASM_WORD=$(if $(CONFIG_64BIT),.quad,.long);\
> - ASM_ALIGN=$(if $(CONFIG_64BIT),3,2); \
> - PROGBITS=$(if $(CONFIG_ARM),%,@)progbits; \
> - echo "/* Generated by firmware/Makefile */" > $@;\
> - echo ".section .rodata" >>$@;\
> - echo ".p2align $${ASM_ALIGN}" >>$@;\
> - echo "_fw_$${FWSTR}_bin:" >>$@;\
> - echo ".incbin \"$(2)\"" >>$@;\
> - echo "_fw_end:" >>$@;\
> - echo " .section .rodata.str,\"aMS\",$${PROGBITS},1" >>$@;\
> - echo ".p2align $${ASM_ALIGN}" >>$@;\
> - echo "_fw_$${FWSTR}_name:">>$@;\
> - echo ".string \"$$FWNAME\"" >>$@;\
> - echo ".section .builtin_fw,\"a\",$${PROGBITS}">>$@;\
> - echo ".p2align $${ASM_ALIGN}" >>$@;\
> - echo "$${ASM_WORD} _fw_$${FWSTR}_name">>$@;\
> - echo "$${ASM_WORD} _fw_$${FWSTR}_bin" >>$@;\
> - echo "$${ASM_WORD} _fw_end - _fw_$${FWSTR}_bin" >>$@;
> -
> -# One of these files will change, or come into existence, whenever
> -# the configuration changes between 32-bit and 64-bit. The .S files
> -# need to change when that happens.
> -wordsize_deps := $(wildcard include/config/64bit.h include/config/32bit.h \
> - include/config/ppc32.h include/config/ppc64.h \
> - include/config/superh32.h include/config/superh64.h \
> - include/config/x86_32.h include/config/x86_64.h \
> - firmware/Makefile)
> -
> -$(patsubst %,$(obj)/%.gen.S, $(fw-external-y)): %: $(wordsize_deps) \
> - include/config/extra/firmware/dir.h
> - $(call cmd,fwbin,$(fwabs)/$(patsubst $(obj)/%.gen.S,%,$@))
> +fwdir := $(addprefix $(srctree)/,$(filter-out /%,$(fwdir)))$(filter
> /%,$(fwdir))
> +
> +obj-y := $(addsuffix .gen.o, $(subst $(quote),,$(CONFIG_EXTRA_FIRMWARE)))
> +
> +FWNAME= $(patsubst $(obj)/%.gen.S,%,$@)
> +FWSTR = $(subst /,_,$(subst .,_,$(subst -,_,$(FWNAME
> +ASM_WORD = $(if $(CONFIG_64BIT),.quad,.long)
> +ASM_ALIGN = $(if $(CONFIG_64BIT),3,2)
> +PROGBITS = $(if $(CONFIG_ARM),%,@)progbits
> +
> +filechk_fwbin = { \
> + echo "/* Generated by $(src)/Makefile */" ;\
> + echo ".section .rodata" ;\
> + echo ".p2align $(ASM_ALIGN)";\
> + echo "_fw_$(FWSTR)_bin:";\
> + echo ".incbin \"$(fwdir)/$(FWNAME)\"" ;\
> + echo "_fw_end:" ;\
> + echo ".section .rodata.str,\"aMS\",$(PROGBITS),1" ;\
> + echo ".p2align $(ASM_ALIGN)";\
> + echo "_fw_$(FWSTR)_name:"
Re: [PATCH v5 0/9] Use vm_insert_range
Having discussed with Matthew offlist, I think we've come to the
following conclusion - there's a number of drivers that buggily
ignore vm_pgoff.
So, what I proposed is:
static int __vm_insert_range(struct vm_struct *vma, struct page *pages,
size_t num, unsigned long offset)
{
unsigned long count = vma_pages(vma);
unsigned long uaddr = vma->vm_start;
int ret;
/* Fail if the user requested offset is beyond the end of the object */
if (offset > num)
return -ENXIO;
/* Fail if the user requested size exceeds available object size */
if (count > num - offset)
return -ENXIO;
/* Never exceed the number of pages that the user requested */
for (i = 0; i < count; i++) {
ret = vm_insert_page(vma, uaddr, pages[offset + i]);
if (ret < 0)
return ret;
uaddr += PAGE_SIZE;
}
return 0;
}
/*
* Maps an object consisting of `num' `pages', catering for the user's
* requested vm_pgoff
*/
int vm_insert_range(struct vm_struct *vma, struct page *pages, size_t num)
{
return __vm_insert_range(vma, pages, num, vma->vm_pgoff);
}
/*
* Maps a set of pages, always starting at page[0]
*/
int vm_insert_range_buggy(struct vm_struct *vma, struct page *pages, size_t num)
{
return __vm_insert_range(vma, pages, num, 0);
}
With this, drivers such as iommu/dma-iommu.c can be converted thusly:
int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct
*vma+)
{
- unsigned long uaddr = vma->vm_start;
- unsigned int i, count = PAGE_ALIGN(size) >> PAGE_SHIFT;
- int ret = -ENXIO;
-
- for (i = vma->vm_pgoff; i < count && uaddr < vma->vm_end; i++) {
- ret = vm_insert_page(vma, uaddr, pages[i]);
- if (ret)
- break;
- uaddr += PAGE_SIZE;
- }
- return ret;
+ return vm_insert_range(vma, pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
}
and drivers such as firewire/core-iso.c:
int fw_iso_buffer_map_vma(struct fw_iso_buffer *buffer,
struct vm_area_struct *vma)
{
- unsigned long uaddr;
- int i, err;
-
- uaddr = vma->vm_start;
- for (i = 0; i < buffer->page_count; i++) {
- err = vm_insert_page(vma, uaddr, buffer->pages[i]);
- if (err)
- return err;
-
- uaddr += PAGE_SIZE;
- }
-
- return 0;
+ return vm_insert_range_buggy(vma, buffer->pages, buffer->page_count);
}
and this gives us something to grep for to find these buggy drivers.
Now, this may not look exactly equivalent, but if you look at
fw_device_op_mmap(), buffer->page_count is basically vma_pages(vma)
at this point, which means this should be equivalent.
We _could_ then at a later date "fix" these drivers to behave according
to the normal vm_pgoff offsetting simply by removing the _buggy suffix
on the function name... and if that causes regressions, it gives us an
easy way to revert (as long as vm_insert_range_buggy() remains
available.)
In the case of firewire/core-iso.c, it currently ignores the mmap offset
entirely, so making the above suggested change would be tantamount to
causing it to return -ENXIO for any non-zero mmap offset.
IMHO, this approach is way simpler, and easier to get it correct at
each call site, rather than the current approach which seems to be
error-prone.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH] kconfig: convert to SPDX License Identifier
On Tue, Dec 18, 2018 at 9:15 PM Masahiro Yamada wrote: > > All files in lxdialog/ are licensed under GPL-2.0+, and the rest are > under GPL-2.0. I added GPL-2.0 tags to python test scripts in tests/. > > Documentation/process/license-rules.rst does not suggest anything > about the flex/bison files. Because flex does not accept the C++ > comment style at the very top of a file, I used the C style for > zconf.l, and so for zconf.y for consistency. > > Signed-off-by: Masahiro Yamada > --- Applied to linux-kbuild/kconfig. > scripts/kconfig/conf.c| 2 +- > scripts/kconfig/confdata.c| 2 +- > scripts/kconfig/expr.c| 2 +- > scripts/kconfig/expr.h| 2 +- > scripts/kconfig/gconf.c | 5 + > scripts/kconfig/images.c | 2 +- > scripts/kconfig/lkc.h | 2 +- > scripts/kconfig/lxdialog/checklist.c | 15 > +-- > scripts/kconfig/lxdialog/dialog.h | 15 > +-- > scripts/kconfig/lxdialog/inputbox.c | 15 > +-- > scripts/kconfig/lxdialog/menubox.c| 15 > +-- > scripts/kconfig/lxdialog/textbox.c| 15 > +-- > scripts/kconfig/lxdialog/util.c | 15 > +-- > scripts/kconfig/lxdialog/yesno.c | 15 > +-- > scripts/kconfig/mconf.c | 2 +- > scripts/kconfig/menu.c| 2 +- > scripts/kconfig/merge_config.sh | 11 ++- > scripts/kconfig/nconf.c | 5 ++--- > scripts/kconfig/nconf.gui.c | 5 ++--- > scripts/kconfig/nconf.h | 5 ++--- > scripts/kconfig/qconf.cc | 2 +- > scripts/kconfig/qconf.h | 2 +- > scripts/kconfig/streamline_config.pl | 2 +- > scripts/kconfig/symbol.c | 2 +- > scripts/kconfig/tests/auto_submenu/__init__.py| 1 + > scripts/kconfig/tests/choice/__init__.py | 1 + > scripts/kconfig/tests/choice_value_with_m_dep/__init__.py | 1 + > scripts/kconfig/tests/err_recursive_inc/__init__.py | 1 + > scripts/kconfig/tests/inter_choice/__init__.py| 1 + > scripts/kconfig/tests/new_choice_with_dep/__init__.py | 1 + > scripts/kconfig/tests/no_write_if_dep_unmet/__init__.py | 1 + > scripts/kconfig/tests/rand_nested_choice/__init__.py | 1 + > scripts/kconfig/util.c| 3 +-- > scripts/kconfig/zconf.l | 8 > scripts/kconfig/zconf.y | 4 ++-- > 35 files changed, 43 insertions(+), 140 deletions(-) > > diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c > index 98e0c7a..da89ef7 100644 > --- a/scripts/kconfig/conf.c > +++ b/scripts/kconfig/conf.c > @@ -1,6 +1,6 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Copyright (C) 2002 Roman Zippel > - * Released under the terms of the GNU GPL v2.0. > */ > > #include > diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c > index 91d0a5c..e32ada9 100644 > --- a/scripts/kconfig/confdata.c > +++ b/scripts/kconfig/confdata.c > @@ -1,6 +1,6 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Copyright (C) 2002 Roman Zippel > - * Released under the terms of the GNU GPL v2.0. > */ > > #include > diff --git a/scripts/kconfig/expr.c b/scripts/kconfig/expr.c > index e1a39e9..ddb9c86 100644 > --- a/scripts/kconfig/expr.c > +++ b/scripts/kconfig/expr.c > @@ -1,6 +1,6 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Copyright (C) 2002 Roman Zippel > - * Released under the terms of the GNU GPL v2.0. > */ > > #include > diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h > index 7c329e1..8807fcf 100644 > --- a/scripts/kconfig/expr.h > +++ b/scripts/kconfig/expr.h > @@ -1,6 +1,6 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > /* > * Copyright (C) 2002 Roman Zippel > - * Released under the terms of the GNU GPL v2.0. > */ > > #ifndef EXPR_H > diff --git a/scripts/kconfig/gconf.c b/scripts/kconfig/gconf.c > index 36f5784..14fc0fa 100644 > --- a/scripts/kconfig/gconf.c > +++ b/scripts/kconfig/gconf.c > @@ -1,9 +1,6 @@ > -/* Hey EMACS -*- linux-c -*- */ > +// SPDX-License-Identifier: GPL-2.0 > /* > - * > * Copyright (C) 2002-2003 Romain Lievin > - * Released under the terms of the GNU GPL v2.0. > - * > */ > > #ifdef HAVE_CONFIG_H > diff --git a/scripts/kconfig/images.c b/scripts/kconfig/images.c > index d4f84bd..ef43b81 100644 > ---
Re: [PATCH 1/5] kconfig: split some C files out of zconf.y
On Sat, Dec 22, 2018 at 12:24 AM Masahiro Yamada wrote: > > I want to compile each C file independently instead of including all > of them from zconf.y. > > These 4 files are low hanging fruits. > > Signed-off-by: Masahiro Yamada > --- Series, applied to linux-kbuild/kconfig. > scripts/kconfig/Makefile | 19 +-- > scripts/kconfig/confdata.c | 1 + > scripts/kconfig/expr.c | 2 ++ > scripts/kconfig/lkc.h| 1 + > scripts/kconfig/preprocess.c | 2 ++ > scripts/kconfig/symbol.c | 2 +- > scripts/kconfig/zconf.y | 4 > 7 files changed, 16 insertions(+), 15 deletions(-) > > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > index 63b6092..d3bd687 100644 > --- a/scripts/kconfig/Makefile > +++ b/scripts/kconfig/Makefile > @@ -142,13 +142,8 @@ help: > @echo ' testconfig - Run Kconfig unit tests (requires python3 > and pytest)' > > # === > -# Shared Makefile for the various kconfig executables: > -# conf: Used for defconfig, oldconfig and related targets > # object files used by all kconfig flavours > - > -conf-objs := conf.o zconf.tab.o > - > -hostprogs-y := conf > +common-objs:= confdata.o expr.o symbol.o preprocess.o zconf.tab.o > > targets+= zconf.lex.c > > @@ -156,9 +151,13 @@ targets+= zconf.lex.c > HOSTCFLAGS_zconf.lex.o := -I$(src) > HOSTCFLAGS_zconf.tab.o := -I$(src) > > +# conf: Used for defconfig, oldconfig and related targets > +hostprogs-y+= conf > +conf-objs := conf.o $(common-objs) > + > # nconf: Used for the nconfig target based on ncurses > hostprogs-y+= nconf > -nconf-objs := nconf.o zconf.tab.o nconf.gui.o > +nconf-objs := nconf.o nconf.gui.o $(common-objs) > > HOSTLDLIBS_nconf = $(shell . $(obj)/.nconf-cfg && echo $$libs) > HOSTCFLAGS_nconf.o = $(shell . $(obj)/.nconf-cfg && echo $$cflags) > @@ -169,7 +168,7 @@ $(obj)/nconf.o $(obj)/nconf.gui.o: $(obj)/.nconf-cfg > # mconf: Used for the menuconfig target based on lxdialog > hostprogs-y+= mconf > lxdialog := checklist.o inputbox.o menubox.o textbox.o util.o yesno.o > -mconf-objs := mconf.o zconf.tab.o $(addprefix lxdialog/, $(lxdialog)) > +mconf-objs := mconf.o $(addprefix lxdialog/, $(lxdialog)) $(common-objs) > > HOSTLDLIBS_mconf = $(shell . $(obj)/.mconf-cfg && echo $$libs) > $(foreach f, mconf.o $(lxdialog), \ > @@ -181,7 +180,7 @@ $(addprefix $(obj)/lxdialog/, $(lxdialog)): > $(obj)/.mconf-cfg > # qconf: Used for the xconfig target based on Qt > hostprogs-y+= qconf > qconf-cxxobjs := qconf.o > -qconf-objs := zconf.tab.o > +qconf-objs := $(common-objs) > > HOSTLDLIBS_qconf = $(shell . $(obj)/.qconf-cfg && echo $$libs) > HOSTCXXFLAGS_qconf.o = $(shell . $(obj)/.qconf-cfg && echo $$cflags) > @@ -196,7 +195,7 @@ $(obj)/%.moc: $(src)/%.h $(obj)/.qconf-cfg > > # gconf: Used for the gconfig target based on GTK+ > hostprogs-y+= gconf > -gconf-objs := gconf.o zconf.tab.o > +gconf-objs := gconf.o $(common-objs) > > HOSTLDLIBS_gconf= $(shell . $(obj)/.gconf-cfg && echo $$libs) > HOSTCFLAGS_gconf.o = $(shell . $(obj)/.gconf-cfg && echo $$cflags) > diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c > index e32ada9..ea88355 100644 > --- a/scripts/kconfig/confdata.c > +++ b/scripts/kconfig/confdata.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/scripts/kconfig/expr.c b/scripts/kconfig/expr.c > index ddb9c86..265f2af 100644 > --- a/scripts/kconfig/expr.c > +++ b/scripts/kconfig/expr.c > @@ -3,6 +3,8 @@ > * Copyright (C) 2002 Roman Zippel > */ > > +#include > +#include > #include > #include > #include > diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h > index 4ff33cd..160a931 100644 > --- a/scripts/kconfig/lkc.h > +++ b/scripts/kconfig/lkc.h > @@ -108,6 +108,7 @@ const char *str_get(struct gstr *gs); > /* symbol.c */ > void sym_clear_all_valid(void); > struct symbol *sym_choice_default(struct symbol *sym); > +struct property *sym_get_range_prop(struct symbol *sym); > const char *sym_get_string_default(struct symbol *sym); > struct symbol *sym_check_deps(struct symbol *sym); > struct property *prop_alloc(enum prop_type type, struct symbol *sym); > diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c > index b028a48..592dfbfa 100644 > --- a/scripts/kconfig/preprocess.c > +++ b/scripts/kconfig/preprocess.c > @@ -2,6 +2,7 @@ > // > // Copyright (C) 2018 Masahiro Yamada > > +#include > #include > #include > #include > @@ -9,6 +10,7 @@ > #include > > #include "list.h" > +#include "lkc.h" > > #define ARRAY_SIZE(arr)(sizeof(arr) / sizeof((arr)[0])) > > diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c > index 364afa1..860414d 100644 > ---
Re: [PATCH] kconfig: remove unused "file" field of yylval union
On Fri, Dec 21, 2018 at 5:59 PM Masahiro Yamada
wrote:
>
> This has never been used.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild/kconfig.
> scripts/kconfig/zconf.y | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
> index 8a4d029..60ee8e7 100644
> --- a/scripts/kconfig/zconf.y
> +++ b/scripts/kconfig/zconf.y
> @@ -36,7 +36,6 @@ static struct menu *current_menu, *current_entry;
> %union
> {
> char *string;
> - struct file *file;
> struct symbol *symbol;
> struct expr *expr;
> struct menu *menu;
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 1/3] treewide: remove explicit rules for *offsets.s
On Sun, Dec 23, 2018 at 7:32 PM Masahiro Yamada wrote: > > These explicit rules are unneeded because scripts/Makefile.build > provides a pattern rule to create %.s from %.c > > Signed-off-by: Masahiro Yamada > --- Series, applied to linux-kbuild. > Kbuild | 9 + > arch/arm/mach-at91/Makefile | 3 --- > arch/arm/mach-omap2/Makefile| 3 --- > arch/ia64/kernel/Makefile | 5 - > drivers/memory/Makefile.asm-offsets | 3 --- > samples/bpf/Makefile| 3 --- > 6 files changed, 1 insertion(+), 25 deletions(-) > > diff --git a/Kbuild b/Kbuild > index 0053042..b24210c 100644 > --- a/Kbuild > +++ b/Kbuild > @@ -16,10 +16,6 @@ bounds-file := include/generated/bounds.h > always := $(bounds-file) > targets := kernel/bounds.s > > -# We use internal kbuild rules to avoid the "is up to date" message from make > -kernel/bounds.s: kernel/bounds.c FORCE > - $(call if_changed_dep,cc_s_c) > - > $(obj)/$(bounds-file): kernel/bounds.s FORCE > $(call filechk,offsets,__LINUX_BOUNDS_H__) > > @@ -50,10 +46,7 @@ offsets-file := include/generated/asm-offsets.h > always += $(offsets-file) > targets += arch/$(SRCARCH)/kernel/asm-offsets.s > > -# We use internal kbuild rules to avoid the "is up to date" message from make > -arch/$(SRCARCH)/kernel/asm-offsets.s: arch/$(SRCARCH)/kernel/asm-offsets.c \ > - $(obj)/$(timeconst-file) > $(obj)/$(bounds-file) FORCE > - $(call if_changed_dep,cc_s_c) > +arch/$(SRCARCH)/kernel/asm-offsets.s: $(obj)/$(timeconst-file) > $(obj)/$(bounds-file) > > $(obj)/$(offsets-file): arch/$(SRCARCH)/kernel/asm-offsets.s FORCE > $(call filechk,offsets,__ASM_OFFSETS_H__) > diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile > index 7415f18..f87066b 100644 > --- a/arch/arm/mach-at91/Makefile > +++ b/arch/arm/mach-at91/Makefile > @@ -19,9 +19,6 @@ ifeq ($(CONFIG_PM_DEBUG),y) > CFLAGS_pm.o += -DDEBUG > endif > > -arch/arm/mach-at91/pm_data-offsets.s: arch/arm/mach-at91/pm_data-offsets.c > - $(call if_changed_dep,cc_s_c) > - > include/generated/at91_pm_data-offsets.h: > arch/arm/mach-at91/pm_data-offsets.s FORCE > $(call filechk,offsets,__PM_DATA_OFFSETS_H__) > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > index 01377c2..55c482c 100644 > --- a/arch/arm/mach-omap2/Makefile > +++ b/arch/arm/mach-omap2/Makefile > @@ -236,9 +236,6 @@ obj-y += > omap_phy_internal.o > > obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o > > -arch/arm/mach-omap2/pm-asm-offsets.s: arch/arm/mach-omap2/pm-asm-offsets.c > - $(call if_changed_dep,cc_s_c) > - > include/generated/ti-pm-asm-offsets.h: arch/arm/mach-omap2/pm-asm-offsets.s > FORCE > $(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__) > > diff --git a/arch/ia64/kernel/Makefile b/arch/ia64/kernel/Makefile > index d0c0ccd..7372d99 100644 > --- a/arch/ia64/kernel/Makefile > +++ b/arch/ia64/kernel/Makefile > @@ -50,10 +50,5 @@ CFLAGS_traps.o += -mfixed-range=f2-f5,f16-f31 > # The gate DSO image is built using a special linker script. > include $(src)/Makefile.gate > > -# We use internal kbuild rules to avoid the "is up to date" message from make > -arch/$(SRCARCH)/kernel/nr-irqs.s: arch/$(SRCARCH)/kernel/nr-irqs.c > - $(Q)mkdir -p $(dir $@) > - $(call if_changed_dep,cc_s_c) > - > include/generated/nr-irqs.h: arch/$(SRCARCH)/kernel/nr-irqs.s FORCE > $(call filechk,offsets,__ASM_NR_IRQS_H__) > diff --git a/drivers/memory/Makefile.asm-offsets > b/drivers/memory/Makefile.asm-offsets > index 843ff60..f968dfa 100644 > --- a/drivers/memory/Makefile.asm-offsets > +++ b/drivers/memory/Makefile.asm-offsets > @@ -1,5 +1,2 @@ > -drivers/memory/emif-asm-offsets.s: drivers/memory/emif-asm-offsets.c > - $(call if_changed_dep,cc_s_c) > - > include/generated/ti-emif-asm-offsets.h: drivers/memory/emif-asm-offsets.s > FORCE > $(call filechk,offsets,__TI_EMIF_ASM_OFFSETS_H__) > diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile > index be0a961..100a49d 100644 > --- a/samples/bpf/Makefile > +++ b/samples/bpf/Makefile > @@ -227,9 +227,6 @@ $(LIBBPF): FORCE > # Fix up variables inherited from Kbuild that tools/ build system won't like > $(MAKE) -C $(dir $@) RM='rm -rf' LDFLAGS= > srctree=$(BPF_SAMPLES_PATH)/../../ O= > > -$(obj)/syscall_nrs.s: $(src)/syscall_nrs.c > - $(call if_changed_dep,cc_s_c) > - > $(obj)/syscall_nrs.h: $(obj)/syscall_nrs.s FORCE > $(call filechk,offsets,__SYSCALL_NRS_H__) > > -- > 2.7.4 > -- Best Regards Masahiro Yamada
Re: You removed Weboob package over political reasons? Whole Internet laughs at you
Debian is not ruled by the men who actually write the software, but instead women. Just like in all the anglo-american conquered world. We, the men who actually do work, are treated as the same worker-slaves everywhere. Opensource was a refuge from the worthless cunts (who ban us from having anything good, such as cute young child brides (allowed by YHWH)) but has not been for some time now. Part and parcel of anglo culture: the man is a dog, the wwmmmannn is a Noble. Now that Linus has caved all is lost. But you can always rescind license for your copyrighted works... (as-long as they are a bare license such as the gpl2). Absent an attached interest (ie: someone paying you for use of the work, or relying on your promises): you the rightsholder have the right to rescind at will. GPL v2 lacks such language disclaiming rescission, you made no utterances that one could rely upon to suggest that there would be no rescission, and you were paid no consideration for your work. .: You can rescind, just like any other property license. And yes, I am a lawyer. Men should be free to take girl children as brides and feminism should be eliminated from the earth (just as they seek to eliminate all pro-male cultures in the world) On 2018-12-24 14:58, Default User wrote: On Mon, Dec 24, 2018, 05:20 Ivan Ivanov 500 comments at Slashdot, >200 at Phoronix and >1000 at linux org ru! See now? When a technical project starts making their decisions over political reasons... rather than technical, it is doomed. Good time to switch to a similar distro with mentally sane leadership, like Devuan. Also what's good about Devuan : Devuan does not use SystemDick as its' init system! SystemD contains 1 million lines of bloated code and lots of vulnerabilities have been found there and countless haven't, also the SystemD creators are arrogant and refuse to fix many discovered security vulnerabilities, to a point where they've been awarded a " Pwnie award " for refusing to fix a critical vuln. That is why I prefer the distros which are using something else as init system: either good old SysV, or something more modern like OpenRC (at Artix Linux) or runit (at Void Linux) , just not systemd! There are only a few such distros left because of Redhat pressure, and luckily Devuan is one of them. If you found Debian as useful before it went nuts then maybe you'd like Devuan, or even some other distros that I mentioned: Artix Linux =Arch with a human face (has GUI + everything configured by default, nice GUI package manager and convenient to use even for the beginners), and Void Linux -amazingly fast distro really suitable for old PCs, but lacks some packages so you'd need to compile the things from source once in a while, in comparison Artix has almost the same set of packages as Arch. Both Artix and Void are very stable despite their packages are really new and they are among the first to get new Linux kernels with fresh drivers. Or maybe MX Linux, one of the top popularity distros nowadays which is also "no systemd" and somehow only recently I learned about it Best regards, Ivan Ivanov, open source firmware developer How ridiculous that some pathetic questionable would spend their precious time on Earth censoring package names which contain the character string "boob". Sad.
Re: [EXT] [PATCH v1] bnx2x: Fix NULL pointer dereference in bnx2x_del_all_vlans() on some hw
On Mon, 2018-12-24 at 14:26 +, Sudarsana Reddy Kalluru wrote:
> Thanks a lot for root-causing the issue and the patch.
> Another (simpler) way to address this would be to invoke
> bnx2x_del_all_vlans() only for the newer chips, e.g.,
> + if (!CHIP_IS_E1(bp)) {
> /* Remove all currently configured VLANs */
>rc = bnx2x_del_all_vlans(bp);
>if (rc < 0)
>BNX2X_ERR("Failed to delete all VLANs\n");
> + }
> Could you please check on this?
Done. See the PATCH v2 in the mailing list. I tested it on my system.
[PATCH] firmware_loader: move CONFIG_FW_LOADER_USER_HELPER switch to Makefile
The whole code of fallback_table.c is surrounded by #ifdef of
CONFIG_FW_LOADER_USER_HELPER.
Move the CONFIG_FW_LOADER_USER_HELPER switch to Makefile so that
it is not compiled at all when this CONFIG is turned off.
I also removed the confusing comment, "Module or buit-in [sic]".
CONFIG_FW_LOADER_USER_HELPER is a boolean option.
(If it were a module, CONFIG_FW_LOADER_USER_HELPER_MODULE would
be defined instead.)
Signed-off-by: Masahiro Yamada
---
drivers/base/firmware_loader/Makefile | 2 +-
drivers/base/firmware_loader/fallback_table.c | 5 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/base/firmware_loader/Makefile
b/drivers/base/firmware_loader/Makefile
index a97eeb0..5c7f422 100644
--- a/drivers/base/firmware_loader/Makefile
+++ b/drivers/base/firmware_loader/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
# Makefile for the Linux firmware loader
-obj-y := fallback_table.o
+obj-$(CONFIG_FW_LOADER_USER_HELPER) += fallback_table.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
firmware_class-objs := main.o
firmware_class-$(CONFIG_FW_LOADER_USER_HELPER) += fallback.o
diff --git a/drivers/base/firmware_loader/fallback_table.c
b/drivers/base/firmware_loader/fallback_table.c
index 7428659..776dd69 100644
--- a/drivers/base/firmware_loader/fallback_table.c
+++ b/drivers/base/firmware_loader/fallback_table.c
@@ -16,9 +16,6 @@
* firmware fallback configuration table
*/
-/* Module or buit-in */
-#ifdef CONFIG_FW_LOADER_USER_HELPER
-
static unsigned int zero;
static unsigned int one = 1;
@@ -51,5 +48,3 @@ struct ctl_table firmware_config_table[] = {
{ }
};
EXPORT_SYMBOL_GPL(firmware_config_table);
-
-#endif
--
2.7.4
[PATCH v2] bnx2x: Fix NULL pointer dereference in bnx2x_del_all_vlans() on some hw
This happened when I tried to boot normal Fedora 29 system with latest
available kernel (from fedora rawhide, plus some unrelated custom
patches):
BUG: unable to handle kernel NULL pointer dereference at
PGD 0 P4D 0
Oops: 0010 [#1] SMP PTI
CPU: 6 PID: 1422 Comm: libvirtd Tainted: G I
4.20.0-0.rc7.git3.hpsa2.1.fc29.x86_64 #1
Hardware name: HP ProLiant BL460c G6, BIOS I24 05/21/2018
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:a47ccdc9fbe0 EFLAGS: 00010246
RAX: RBX: 03e8 RCX: a47ccdc9fbf8
RDX: a47ccdc9fc00 RSI: 97d9ee7b01f8 RDI: 97d9f0150b80
RBP: 97d9f0150b80 R08: R09:
R10: R11: R12: 0003
R13: 97d9ef1e53e8 R14: 0009 R15: 97d9f0ac6730
FS: 7f4d224ef700() GS:97d9fa20()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: ffd6 CR3: 0011ece52006 CR4: 000206e0
Call Trace:
? bnx2x_chip_cleanup+0x195/0x610 [bnx2x]
? bnx2x_nic_unload+0x1e2/0x8f0 [bnx2x]
? bnx2x_reload_if_running+0x24/0x40 [bnx2x]
? bnx2x_set_features+0x79/0xa0 [bnx2x]
? __netdev_update_features+0x244/0x9e0
? netlink_broadcast_filtered+0x136/0x4b0
? netdev_update_features+0x22/0x60
? dev_disable_lro+0x1c/0xe0
? devinet_sysctl_forward+0x1c6/0x211
? proc_sys_call_handler+0xab/0x100
? __vfs_write+0x36/0x1a0
? rcu_read_lock_sched_held+0x79/0x80
? rcu_sync_lockdep_assert+0x2e/0x60
? __sb_start_write+0x14c/0x1b0
? vfs_write+0x159/0x1c0
? vfs_write+0xba/0x1c0
? ksys_write+0x52/0xc0
? do_syscall_64+0x60/0x1f0
? entry_SYSCALL_64_after_hwframe+0x49/0xbe
After some investigation I figured out that recently added cleanup code
tries to call VLAN filtering de-initialization function which exist only
for newer hardware. Corresponding function pointer is not
set (== 0) for older hardware, namely these chips:
#define CHIP_NUM_57710 0x164e
#define CHIP_NUM_57711 0x164f
#define CHIP_NUM_57711E 0x1650
And I have one of those in my test system:
Broadcom Inc. and subsidiaries NetXtreme II BCM57711E 10-Gigabit PCIe
[14e4:1650]
Function bnx2x_init_vlan_mac_fp_objs() from
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h decides whether to
initialize relevant pointers in bnx2x_sp_objs.vlan_obj or not.
This regression was introduced after v4.20-rc7, and still exists in v4.20
release.
Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload
sequence.")
Signed-off-by: Ivan Mironov
---
v2:
- As suggested by Sudarsana Reddy Kalluru, do not call bnx2x_del_all_vlans() at
all if (!CHIP_IS_E1x(bp)).
v1:
- Check for chip num instead of (vlan_obj->delete_all != 0).
v0:
- Patch introduced.
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index b164f705709d..3b5b47e98c73 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9360,10 +9360,16 @@ void bnx2x_chip_cleanup(struct bnx2x *bp, int
unload_mode, bool keep_link)
BNX2X_ERR("Failed to schedule DEL commands for UC MACs list:
%d\n",
rc);
- /* Remove all currently configured VLANs */
- rc = bnx2x_del_all_vlans(bp);
- if (rc < 0)
- BNX2X_ERR("Failed to delete all VLANs\n");
+ /* The whole *vlan_obj structure may be not initialized if VLAN
+* filtering offload is not supported by hardware. Currently this is
+* true for all hardware covered by CHIP_IS_E1x().
+*/
+ if (!CHIP_IS_E1x(bp)) {
+ /* Remove all currently configured VLANs */
+ rc = bnx2x_del_all_vlans(bp);
+ if (rc < 0)
+ BNX2X_ERR("Failed to delete all VLANs\n");
+ }
/* Disable LLH */
if (!CHIP_IS_E1(bp))
--
2.20.1
Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup
On Mon, Dec 24, 2018 at 03:52:55PM +0100, Noralf Trønnes wrote:
>
>
> Den 24.12.2018 00.10, skrev Peter Wu:
> > On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote:
> > >
> > >
> > > Den 23.12.2018 01.55, skrev Peter Wu:
> > > > After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
> > > > "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
> > > > have some effect). After that, drm_fb_helper_initial_config is called
> > > > which may call the "fb_probe" driver callback.
> > > >
> > > > This driver callback may call drm_fb_helper_defio_init (as is done by
> > > > drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
> > > > as documented. These are normally cleaned up on exit by
> > > > drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.
> > > >
> > > > If an error occurs after "fb_probe", but before setup is complete, then
> > > > calling just drm_fb_helper_fini will leak resources. This was triggered
> > > > by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):
> > > >
> > > > [ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to
> > > > support this framebuffer
> > > > [ 50.009436] bochs-drm :00:02.0:
> > > > [drm:drm_fb_helper_fbdev_setup] *ERROR* fbdev: Failed to set
> > > > configuration (ret=-38)
> > > > [ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for
> > > > :00:02.0 on minor 2
> > > > [ 50.013604] WARNING: CPU: 1 PID: 1 at
> > > > drivers/gpu/drm/drm_mode_config.c:477
> > > > drm_mode_config_cleanup+0x280/0x2a0
> > > > [ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G
> > > > T 4.20.0-rc7 #1
> > > > [ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
> > > > ...
> > > > [ 50.023155] Call Trace:
> > > > [ 50.023155] ? bochs_kms_fini+0x1e/0x30
> > > > [ 50.023155] ? bochs_unload+0x18/0x40
> > > >
> > > > This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n.
> > > >
> > > > Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian
> > > > Link: https://lkml.kernel.org/r/20181223004315.GA11455@al
> > > > Fixes: 8741216396b2 ("drm/fb-helper: Add
> > > > drm_fb_helper_fbdev_setup/teardown()")
> > > > Reported-by: kernel test robot
> > > > Cc: Noralf Trønnes
> > > > Signed-off-by: Peter Wu
> > > > ---
> > > >drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > > b/drivers/gpu/drm/drm_fb_helper.c
> > > > index 9d64f874f965..432e0f3b9267 100644
> > > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > > @@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device
> > > > *dev,
> > > > return 0;
> > > >err_drm_fb_helper_fini:
> > > > - drm_fb_helper_fini(fb_helper);
> > > > + drm_fb_helper_fbdev_teardown(dev);
> > >
> > > This change will break the error path for drm_fbdev_generic_setup()
> > > because drm_fb_helper_generic_probe() cleans up on error but doesn't
> > > clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove().
> >
> > This should probably considered a bug of drm_fb_helper_generic_probe.
> > Ownership of fb_helper should remain with the caller. The caller can
> > detect an error and act accordingly.
> >
> > > My assumption has been that the drm_fb_helper_funcs->fb_probe callback
> > > cleans up its resources on error. Clearly this is not the case for bochs,
> > > so
> > > my take on this is that bochsfb_create() needs to clean up on error.
> >
> > That assumption still holds for bochs. The problem is this sequence:
> > - drm_fb_helper_fbdev_setup is called.
> > - fb_probe succeeds (this is crucial).
> > - register_framebuffer fails.
> > - error path of setup is triggered.
> >
> > As fb_helper is fully setup by drivers, the drm_fb_helper core should
> > fully deallocate it again on the error path or else a leak occurs.
> >
> > > Gerd has a patchset that switches bochs over to the generic fbdev
> > > emulation, but ofc that doesn't help with 4.20:
> > > https://patchwork.freedesktop.org/series/54269/
> >
> > And that does not help with other users of the drm_fb_helper who use
> > functions like drm_fb_helper_defio_init. They will likely run in the
> > same problem.
> >
> > I don't have a way to test tinydrm or other drivers, but if you force
> > register_framebuffer to fail, you should be able to reproduce the
> > problem with drm_fb_helper_generic_probe.
> >
>
> Now I understand. I have looked at the drivers that use drm_fb_helper
> and no one seem to handle the case where register_framebuffer() is
> failing.
>
> Here's what drivers do when drm_fb_helper_initial_config() fails:
>
> Doesn't check:
> amdgpu
> virtio
>
> Calls drm_fb_helper_fini():
> armada
> ast
> exynos
> gma500
> hisilicon
> mgag200
> msm
> nouveau
> omap
> radeon
>
Re: [PATCH V2] SelfTest: KVM: Drop Asserts for madvise MADV_NOHUGEPAGE failure
Kind reminder to merge my patch into next
thanks.
On Fri, Nov 16, 2018 at 2:59 PM Andrew Jones wrote:
>
> On Fri, Nov 16, 2018 at 01:50:55PM +0200, Ahmed Abd El Mawgood wrote:
> > From: Ahmed Abd El Mawgood
> >
> > madvise() returns -1 without CONFIG_TRANSPARENT_HUGEPAGE=y. That would
> > trigger asserts when checking for return value of madvice. Following
> > similar decision to [1]. I thought it is ok to assume that madvise()
> > MADV_NOHUGEPAGE failures implies that THP is not supported by host kernel.
> >
> > Other options was to check for Transparent Huge Page support in
> > /sys/kernel/mm/transparent_hugepage/enabled.
> >
> > -- links --
> > [1] https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04514.html
> >
> > Signed-off-by: Ahmed Abd El Mawgood
> > ---
> > tools/testing/selftests/kvm/lib/kvm_util.c | 21 +++--
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c
> > b/tools/testing/selftests/kvm/lib/kvm_util.c
> > index 1b41e71283d5..437c5bb48061 100644
> > --- a/tools/testing/selftests/kvm/lib/kvm_util.c
> > +++ b/tools/testing/selftests/kvm/lib/kvm_util.c
> > @@ -586,14 +586,23 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,
> >src_type == VM_MEM_SRC_ANONYMOUS_THP ?
> > huge_page_size : 1);
> >
> > /* As needed perform madvise */
> > - if (src_type == VM_MEM_SRC_ANONYMOUS || src_type ==
> > VM_MEM_SRC_ANONYMOUS_THP) {
> > + if (src_type == VM_MEM_SRC_ANONYMOUS) {
> > + /*
> > + * Neglect madvise error because it is ok to not have THP
> > + * support in this case.
> > + */
> > + madvise(region->host_mem, npages * vm->page_size,
> > + MADV_NOHUGEPAGE);
> > + } else if (src_type == VM_MEM_SRC_ANONYMOUS_THP) {
> > ret = madvise(region->host_mem, npages * vm->page_size,
> > - src_type == VM_MEM_SRC_ANONYMOUS ?
> > MADV_NOHUGEPAGE : MADV_HUGEPAGE);
> > + MADV_HUGEPAGE);
> > TEST_ASSERT(ret == 0, "madvise failed,\n"
> > - " addr: %p\n"
> > - " length: 0x%lx\n"
> > - " src_type: %x",
> > - region->host_mem, npages * vm->page_size,
> > src_type);
> > + "Does the kernel have CONFIG_TRANSPARENT_HUGEPAGE=y\n"
> > + " addr: %p\n"
> > + " length: 0x%lx\n"
> > + " src_type: %x\n",
> > + region->host_mem, npages * vm->page_size,
> > + src_type);
> > }
> >
> > region->unused_phy_pages = sparsebit_alloc();
> > --
> > 2.18.1
> >
>
> Reviewed-by: Andrew Jones
--
Junior Researcher, IoT and Cyber Security lab, SmartCI, Alexandria
University, & CIS @ VMI
Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup
Den 24.12.2018 00.10, skrev Peter Wu:
On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote:
Den 23.12.2018 01.55, skrev Peter Wu:
After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
"dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
have some effect). After that, drm_fb_helper_initial_config is called
which may call the "fb_probe" driver callback.
This driver callback may call drm_fb_helper_defio_init (as is done by
drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
as documented. These are normally cleaned up on exit by
drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.
If an error occurs after "fb_probe", but before setup is complete, then
calling just drm_fb_helper_fini will leak resources. This was triggered
by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):
[ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this
framebuffer
[ 50.009436] bochs-drm :00:02.0: [drm:drm_fb_helper_fbdev_setup]
*ERROR* fbdev: Failed to set configuration (ret=-38)
[ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for
:00:02.0 on minor 2
[ 50.013604] WARNING: CPU: 1 PID: 1 at
drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0
[ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GT
4.20.0-rc7 #1
[ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
...
[ 50.023155] Call Trace:
[ 50.023155] ? bochs_kms_fini+0x1e/0x30
[ 50.023155] ? bochs_unload+0x18/0x40
This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n.
Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian
Link: https://lkml.kernel.org/r/20181223004315.GA11455@al
Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()")
Reported-by: kernel test robot
Cc: Noralf Trønnes
Signed-off-by: Peter Wu
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9d64f874f965..432e0f3b9267 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device *dev,
return 0;
err_drm_fb_helper_fini:
- drm_fb_helper_fini(fb_helper);
+ drm_fb_helper_fbdev_teardown(dev);
This change will break the error path for drm_fbdev_generic_setup()
because drm_fb_helper_generic_probe() cleans up on error but doesn't
clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove().
This should probably considered a bug of drm_fb_helper_generic_probe.
Ownership of fb_helper should remain with the caller. The caller can
detect an error and act accordingly.
My assumption has been that the drm_fb_helper_funcs->fb_probe callback
cleans up its resources on error. Clearly this is not the case for bochs, so
my take on this is that bochsfb_create() needs to clean up on error.
That assumption still holds for bochs. The problem is this sequence:
- drm_fb_helper_fbdev_setup is called.
- fb_probe succeeds (this is crucial).
- register_framebuffer fails.
- error path of setup is triggered.
As fb_helper is fully setup by drivers, the drm_fb_helper core should
fully deallocate it again on the error path or else a leak occurs.
Gerd has a patchset that switches bochs over to the generic fbdev
emulation, but ofc that doesn't help with 4.20:
https://patchwork.freedesktop.org/series/54269/
And that does not help with other users of the drm_fb_helper who use
functions like drm_fb_helper_defio_init. They will likely run in the
same problem.
I don't have a way to test tinydrm or other drivers, but if you force
register_framebuffer to fail, you should be able to reproduce the
problem with drm_fb_helper_generic_probe.
Now I understand. I have looked at the drivers that use drm_fb_helper
and no one seem to handle the case where register_framebuffer() is
failing.
Here's what drivers do when drm_fb_helper_initial_config() fails:
Doesn't check:
amdgpu
virtio
Calls drm_fb_helper_fini():
armada
ast
exynos
gma500
hisilicon
mgag200
msm
nouveau
omap
radeon
rockchip
tegra
udl
bochs - Uses drm_fb_helper_fbdev_setup()
qxl - Uses drm_fb_helper_fbdev_setup()
vboxvideo - Uses drm_fb_helper_fbdev_setup()
Might clean up, not sure:
cirrus
Looks suspicious:
i915
I looked at bochs before it switched to drm_fb_helper_fbdev_setup() and
it also just called drm_fb_helper_fini().
It looks like you've uncovered something no one has though about (or
not implemented at least).
It's not just the framebuffer that's not destroyed, the buffer object
is also leaked. drm_mode_config_cleanup() yells about the framebuffer
(and frees it), but says nothing about the buffer object. It might be
that it can't even be made to detect that since some drivers do special
stuff for the fbdev buffer.
I'll pick up on
Re: [PATCH v2 3/3] ASoC: cros_ec_codec: Add codec driver for Cros EC
On Mon, Dec 24, 2018 at 12:45 AM Cheng-Yi Chiang wrote:
>
> Add a codec driver to control ChromeOS EC codec.
>
> Use EC Host command to enable/disable I2S recording and control other
> configurations.
>
> Signed-off-by: Cheng-Yi Chiang
> ---
> Addressed Enric's comments.
>
> Changes in v2:
> - Many style fixes. Passed checkpatch.pl --strict.
> - Use ChromeOS naming.
> - Remove license boilerplate.
> - Use u8 instead of uint8_t.
> - Remove useless debug messages.
> - Remove useless remove ops.
> - Remove -EPROBE_DEFER in probe.
>
> MAINTAINERS | 2 +
> sound/soc/codecs/Kconfig | 8 +
> sound/soc/codecs/Makefile| 2 +
> sound/soc/codecs/cros_ec_codec.c | 458 +++
> sound/soc/codecs/cros_ec_codec.h | 21 ++
> 5 files changed, 491 insertions(+)
> create mode 100644 sound/soc/codecs/cros_ec_codec.c
> create mode 100644 sound/soc/codecs/cros_ec_codec.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 05e1922624e58..d66f80f3252d7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3638,8 +3638,10 @@ F: drivers/platform/chrome/
>
> CHROMEOS EC CODEC DRIVER
> M: Cheng-Yi Chiang
> +R: Enric Balletbo i Serra
> S: Maintained
> F: Documentation/devicetree/bindings/sound/google,cros-ec-codec.txt
> +F: sound/soc/codecs/cros_ec_codec.*
>
> CIRRUS LOGIC AUDIO CODEC DRIVERS
> M: Brian Austin
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index 87cb9c51e6f5a..0b36428159b71 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -50,6 +50,7 @@ config SND_SOC_ALL_CODECS
> select SND_SOC_BT_SCO
> select SND_SOC_BD28623
> select SND_SOC_CQ0093VC
> + select SND_SOC_CROS_EC_CODEC
> select SND_SOC_CS35L32 if I2C
> select SND_SOC_CS35L33 if I2C
> select SND_SOC_CS35L34 if I2C
> @@ -457,6 +458,13 @@ config SND_SOC_CPCAP
> config SND_SOC_CQ0093VC
> tristate
>
> +config SND_SOC_CROS_EC_CODEC
> + tristate "codec driver for ChromeOS EC"
> + depends on MFD_CROS_EC
> + help
> + If you say yes here you will get support for the
> + ChromeOS Embedded Controller's Audio Codec.
> +
> config SND_SOC_CS35L32
> tristate "Cirrus Logic CS35L32 CODEC"
> depends on I2C
> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
> index 9bb3346fab2fe..3cfd8f5f61705 100644
> --- a/sound/soc/codecs/Makefile
> +++ b/sound/soc/codecs/Makefile
> @@ -42,6 +42,7 @@ snd-soc-bd28623-objs := bd28623.o
> snd-soc-bt-sco-objs := bt-sco.o
> snd-soc-cpcap-objs := cpcap.o
> snd-soc-cq93vc-objs := cq93vc.o
> +snd-soc-cros-ec-codec-objs := cros_ec_codec.o
> snd-soc-cs35l32-objs := cs35l32.o
> snd-soc-cs35l33-objs := cs35l33.o
> snd-soc-cs35l34-objs := cs35l34.o
> @@ -310,6 +311,7 @@ obj-$(CONFIG_SND_SOC_BD28623) += snd-soc-bd28623.o
> obj-$(CONFIG_SND_SOC_BT_SCO) += snd-soc-bt-sco.o
> obj-$(CONFIG_SND_SOC_CQ0093VC) += snd-soc-cq93vc.o
> obj-$(CONFIG_SND_SOC_CPCAP)+= snd-soc-cpcap.o
> +obj-$(CONFIG_SND_SOC_CROS_EC_CODEC)+= snd-soc-cros-ec-codec.o
> obj-$(CONFIG_SND_SOC_CS35L32) += snd-soc-cs35l32.o
> obj-$(CONFIG_SND_SOC_CS35L33) += snd-soc-cs35l33.o
> obj-$(CONFIG_SND_SOC_CS35L34) += snd-soc-cs35l34.o
> diff --git a/sound/soc/codecs/cros_ec_codec.c
> b/sound/soc/codecs/cros_ec_codec.c
> new file mode 100644
> index 0..39e61bf46b5c0
> --- /dev/null
> +++ b/sound/soc/codecs/cros_ec_codec.c
> @@ -0,0 +1,458 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for ChromeOS Embedded Controller codec.
> + *
> + * This driver uses the cros-ec interface to communicate with the ChromeOS
> + * EC for audio function.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "cros_ec_codec.h"
> +
> +#define MAX_GAIN 43
> +
> +#define DRV_NAME "cros-ec-codec"
> +
> +static const DECLARE_TLV_DB_SCALE(ec_mic_gain_tlv, 0, 100, 0);
> +/*
> + * Wrapper for EC command.
> + */
> +static int ec_command(struct snd_soc_component *component, int version,
> + int command, u8 *outdata, int outsize,
> + u8 *indata, int insize)
> +{
> + struct cros_ec_codec_data *codec_data =
> + snd_soc_component_get_drvdata(component);
> + struct cros_ec_device *ec_device = codec_data->ec_device;
> + struct cros_ec_command *msg;
> + int ret;
> +
> + msg = kzalloc(sizeof(*msg) + max(insize, outsize), GFP_KERNEL);
> + if (!msg)
> + return -ENOMEM;
> +
> + msg->version = version;
> + msg->command = command;
> + msg->outsize = outsize;
> + msg->insize = insize;
> +
> + if (outsize)
> + memcpy(msg->data, outdata, outsize);
> +
> + ret = cros_ec_cmd_xfer_status(ec_device, msg);
> + if (ret > 0 && insize)
> +
Re: [PATCH v2] fs: fix possible Spectre V1 indexing in __close_fd()
On Mon, Dec 24, 2018 at 06:26:42AM -0800, Greg Hackmann wrote: > +++ b/fs/file.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > > unsigned int sysctl_nr_open __read_mostly = 1024*1024; > unsigned int sysctl_nr_open_min = BITS_PER_LONG; > @@ -626,6 +627,7 @@ int __close_fd(struct files_struct *files, unsigned fd) > fdt = files_fdtable(files); > if (fd >= fdt->max_fds) > goto out_unlock; > + fd = array_index_nospec(fd, fdt->max_fds); > file = fdt->fd[fd]; > if (!file) > goto out_unlock; This is insufficient. do_dup2() has a similar problem.
Re: [PATCH v2 2/3] ASoC: Documentation: Add google,cros-ec-codec
On Mon, Dec 24, 2018 at 12:39 AM Cheng-Yi Chiang wrote:
>
> Add documentation for Chrome EC codec driver.
>
> Signed-off-by: Cheng-Yi Chiang
> ---
> Change in v2: Fixed name of driver in MAINTAINERS.
>
> .../bindings/sound/google,cros-ec-codec.txt | 24 +++
Since this is a devicetree binding, it will require an Ack from a DT
maintainer. You might want to check the output of
scripts/get_maintainer.pl to make sure you don't miss anyone
important.
Guenter
> MAINTAINERS | 5
> 2 files changed, 29 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/sound/google,cros-ec-codec.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.txt
> b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.txt
> new file mode 100644
> index 0..57718382b3a36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.txt
> @@ -0,0 +1,24 @@
> +* Audio codec controlled by ChromeOS EC
> +
> +Google's ChromeOS EC codec is a digital mic codec provided by the
> +Embedded Controller (EC) and is controlled via a host-command interface.
> +
> +An EC codec node should only be found as a sub-node of the EC node (see
> +Documentation/devicetree/bindings/mfd/cros-ec.txt).
> +
> +Required properties:
> +- compatible: Must contain "google,cros-ec-codec"
> +- #sound-dai-cells: Should be 1. The cell specifies number of DAIs.
> +
> +Example:
> +
> +cros-ec@0 {
> + compatible = "google,cros-ec-spi";
> +
> + ...
> +
> + cros_ec_codec: ec-codec {
> + compatible = "google,cros-ec-codec";
> + #sound-dai-cells = <1>;
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5b9c6af98283b..05e1922624e58 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3636,6 +3636,11 @@ S: Maintained
> T: git
> git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
> F: drivers/platform/chrome/
>
> +CHROMEOS EC CODEC DRIVER
> +M: Cheng-Yi Chiang
> +S: Maintained
> +F: Documentation/devicetree/bindings/sound/google,cros-ec-codec.txt
> +
> CIRRUS LOGIC AUDIO CODEC DRIVERS
> M: Brian Austin
> M: Paul Handrigan
> --
> 2.20.1.415.g653613c723-goog
>
[PATCH] drm/drm_drv.c: Remove duplicate header
Remove drm_crtc_internal.h which is included more than once Signed-off-by: Brajeswar Ghosh --- drivers/gpu/drm/drm_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 4126bb6e1a4a..75f4e6bf67ca 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -41,7 +41,6 @@ #include "drm_crtc_internal.h" #include "drm_legacy.h" #include "drm_internal.h" -#include "drm_crtc_internal.h" /* * drm_debug: Enable debug output. -- 2.17.1
[PATCH] drm/bridge/panel: Remove duplicate header
Remove drm/drm_panel.h which is included more than once
Signed-off-by: Brajeswar Ghosh
---
drivers/gpu/drm/bridge/panel.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 7cbaba213ef6..402b318eeeb2 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
struct panel_bridge {
struct drm_bridge bridge;
--
2.17.1
Re: [PATCH v5 6/9] iommu/dma-iommu.c: Convert to use vm_insert_range
On Mon, Dec 24, 2018 at 06:55:31PM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> ---
> drivers/iommu/dma-iommu.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index d1b0475..de7ffd8 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -622,17 +622,10 @@ struct page **iommu_dma_alloc(struct device *dev,
> size_t size, gfp_t gfp,
>
> int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct
> *vma)
> {
> - unsigned long uaddr = vma->vm_start;
> - unsigned int i, count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> - int ret = -ENXIO;
> + unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
>
> - for (i = vma->vm_pgoff; i < count && uaddr < vma->vm_end; i++) {
> - ret = vm_insert_page(vma, uaddr, pages[i]);
> - if (ret)
> - break;
> - uaddr += PAGE_SIZE;
> - }
> - return ret;
> + return vm_insert_range(vma, vma->vm_start, pages + vma->vm_pgoff,
> + count - vma->vm_pgoff);
This introduces a new bug.
I'm not going to continue to point out in minute detail the mistakes
you are introducing, as I don't think that is helping you to learn.
Look at this closely, and see whether you can spot the mistake.
Specifically, compare the boundary conditions for the final page
that is to be inserted and the value returned by the original version
and by your version for different scenarios.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
[PATCH v2] fs: fix possible Spectre V1 indexing in __close_fd()
Omer Tripp's analysis of a Spectre V1 gadget in __close_fd(): "1. __close_fd() is reachable via the close() syscall with a user-controlled fd. 2. If said bounds check is mispredicted, then a user-controlled address fdt->fd[fd] is obtained then dereferenced, and the value of a user-controlled address is loaded into the local variable file. 3. file is then passed as an argument to filp_close, where the cache lines secret + offsetof(f_op) and secret + offsetof(f_mode) are hot and vulnerable to a timing channel attack." Address this by using array_index_nospec() to prevent speculation past the end of current->fdt. Reported-by: Omer Tripp Cc: sta...@vger.kernel.org Signed-off-by: Greg Hackmann --- v2: include Omer Tripp's analysis in commit message, and update my email address fs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/file.c b/fs/file.c index 7ffd6e9d103d..a80cf82be96b 100644 --- a/fs/file.c +++ b/fs/file.c @@ -18,6 +18,7 @@ #include #include #include +#include unsigned int sysctl_nr_open __read_mostly = 1024*1024; unsigned int sysctl_nr_open_min = BITS_PER_LONG; @@ -626,6 +627,7 @@ int __close_fd(struct files_struct *files, unsigned fd) fdt = files_fdtable(files); if (fd >= fdt->max_fds) goto out_unlock; + fd = array_index_nospec(fd, fdt->max_fds); file = fdt->fd[fd]; if (!file) goto out_unlock; -- 2.19.1
RE: [EXT] [PATCH v1] bnx2x: Fix NULL pointer dereference in bnx2x_del_all_vlans() on some hw
-Original Message-
From: Ivan Mironov [mailto:mironov.i...@gmail.com]
Sent: 24 December 2018 17:26
To: net...@vger.kernel.org
Cc: Ariel Elior ; Sudarsana Kalluru
; everest-linux...@cavium.com; David S. Miller
; linux-kernel@vger.kernel.org; Ivan Mironov
Subject: [EXT] [PATCH v1] bnx2x: Fix NULL pointer dereference in
bnx2x_del_all_vlans() on some hw
External Email
--
External Email
This happened when I tried to boot normal Fedora 29 system with latest
available kernel (from fedora rawhide, plus some unrelated custom
patches):
BUG: unable to handle kernel NULL pointer dereference at
PGD 0 P4D 0
Oops: 0010 [#1] SMP PTI
CPU: 6 PID: 1422 Comm: libvirtd Tainted: G I
4.20.0-0.rc7.git3.hpsa2.1.fc29.x86_64 #1
Hardware name: HP ProLiant BL460c G6, BIOS I24 05/21/2018
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:a47ccdc9fbe0 EFLAGS: 00010246
RAX: RBX: 03e8 RCX: a47ccdc9fbf8
RDX: a47ccdc9fc00 RSI: 97d9ee7b01f8 RDI: 97d9f0150b80
RBP: 97d9f0150b80 R08: R09:
R10: R11: R12: 0003
R13: 97d9ef1e53e8 R14: 0009 R15: 97d9f0ac6730
FS: 7f4d224ef700() GS:97d9fa20()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: ffd6 CR3: 0011ece52006 CR4: 000206e0
Call Trace:
? bnx2x_chip_cleanup+0x195/0x610 [bnx2x]
? bnx2x_nic_unload+0x1e2/0x8f0 [bnx2x]
? bnx2x_reload_if_running+0x24/0x40 [bnx2x]
? bnx2x_set_features+0x79/0xa0 [bnx2x]
? __netdev_update_features+0x244/0x9e0
? netlink_broadcast_filtered+0x136/0x4b0
? netdev_update_features+0x22/0x60
? dev_disable_lro+0x1c/0xe0
? devinet_sysctl_forward+0x1c6/0x211
? proc_sys_call_handler+0xab/0x100
? __vfs_write+0x36/0x1a0
? rcu_read_lock_sched_held+0x79/0x80
? rcu_sync_lockdep_assert+0x2e/0x60
? __sb_start_write+0x14c/0x1b0
? vfs_write+0x159/0x1c0
? vfs_write+0xba/0x1c0
? ksys_write+0x52/0xc0
? do_syscall_64+0x60/0x1f0
? entry_SYSCALL_64_after_hwframe+0x49/0xbe
After some investigation I figured out that recently added cleanup code tries
to call VLAN filtering de-initialization function which exist only for newer
hardware. Corresponding function pointer is not set (== 0) for older hardware,
namely these chips:
#define CHIP_NUM_57710 0x164e
#define CHIP_NUM_57711 0x164f
#define CHIP_NUM_57711E 0x1650
And I have one of those in my test system:
Broadcom Inc. and subsidiaries NetXtreme II BCM57711E 10-Gigabit PCIe
[14e4:1650]
Function bnx2x_init_vlan_mac_fp_objs() from
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h decides whether to initialize
relevant pointers in bnx2x_sp_objs.vlan_obj or not.
This regression was introduced after v4.20-rc7, and still exists in v4.20
release.
Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload
sequence.")
Signed-off-by: Ivan Mironov
---
v1:
- Check for chip num instead of (vlan_obj->delete_all != 0).
v0:
- Patch introduced.
---
.../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 22 +--
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index b164f705709d..4d72e9948a58 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -8504,15 +8504,23 @@ int bnx2x_set_vlan_one(struct bnx2x *bp, u16 vlan,
static int bnx2x_del_all_vlans(struct bnx2x *bp) {
struct bnx2x_vlan_mac_obj *vlan_obj = >sp_objs[0].vlan_obj;
- unsigned long ramrod_flags = 0, vlan_flags = 0;
struct bnx2x_vlan_entry *vlan;
- int rc;
- __set_bit(RAMROD_COMP_WAIT, _flags);
- __set_bit(BNX2X_VLAN, _flags);
- rc = vlan_obj->delete_all(bp, vlan_obj, _flags, _flags);
- if (rc)
- return rc;
+ /* The whole *vlan_obj structure may be not initialized if VLAN
+* filtering offload is not supported by hardware. Currently this is
+* true for all hardware covered by CHIP_IS_E1x().
+*/
+ if (!CHIP_IS_E1x(bp)) {
+ unsigned long ramrod_flags = 0, vlan_flags = 0;
+ int rc;
+
+ __set_bit(RAMROD_COMP_WAIT, _flags);
+ __set_bit(BNX2X_VLAN, _flags);
+ rc = vlan_obj->delete_all(bp, vlan_obj, _flags,
+ _flags);
+ if (rc)
+
[PATCH] kbuild: remove unused cmd_gentimeconst
filechk_gentimeconst is always used instead of cmd_gentimeconst. Signed-off-by: Masahiro Yamada --- Kbuild | 4 1 file changed, 4 deletions(-) diff --git a/Kbuild b/Kbuild index 640557d..4455dfd 100644 --- a/Kbuild +++ b/Kbuild @@ -25,10 +25,6 @@ timeconst-file := include/generated/timeconst.h targets += $(timeconst-file) -quiet_cmd_gentimeconst = GEN $@ -define cmd_gentimeconst - (echo $(CONFIG_HZ) | bc -q $< ) > $@ -endef define filechk_gentimeconst (echo $(CONFIG_HZ) | bc -q $< ) endef -- 2.7.4
[PATCH v1 4/4] perf report: support record trace file decompression
PERF_RECORD_COMPRESSED records are decompressed from trace file into a
linked list of mmaped memory regions using Zstandard API. After that the
region is loaded fetching uncompressed events. When dumping raw trace
like perf report -D file offsets of events from compressed records are
set to zero.
Signed-off-by: Alexey Budankov
---
tools/perf/builtin-report.c | 151 +++-
tools/perf/util/machine.c | 4 +
tools/perf/util/session.c | 59 +-
tools/perf/util/session.h | 16
tools/perf/util/tool.h | 2 +
5 files changed, 230 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 4958095be4fc..1c45e674743d 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -52,7 +52,10 @@
#include
#include
#include
-#include
+#include
+#ifdef HAVE_ZSTD_SUPPORT
+#include
+#endif
struct report {
struct perf_tooltool;
@@ -118,6 +121,94 @@ static int report__config(const char *var, const char
*value, void *cb)
return 0;
}
+#ifdef HAVE_ZSTD_SUPPORT
+static int report__zstd_init(struct perf_session *session)
+{
+ size_t ret;
+
+ session->zstd_dstream = ZSTD_createDStream();
+ if (session->zstd_dstream == NULL)
+ {
+ pr_err("Couldn't create decompression stream, disables trace
compression\n");
+ return -1;
+ }
+
+ ret = ZSTD_initDStream(session->zstd_dstream);
+ if (ZSTD_isError(ret))
+ {
+ pr_err("Failed to initialize decompression stream: %s\n",
ZSTD_getErrorName(ret));
+ return -1;
+ }
+
+ return 0;
+}
+
+static int report__zstd_fini(struct perf_session *session)
+{
+ struct decomp *next = session->decomp, *decomp;
+ size_t decomp_len = session->header.env.comp_mmap_len;
+
+ if (session->zstd_dstream) {
+ ZSTD_freeDStream(session->zstd_dstream);
+ session->zstd_dstream = NULL;
+ }
+
+ do {
+ decomp = next;
+ if (decomp == NULL)
+ break;
+ next = decomp->next;
+ munmap(decomp, decomp_len + sizeof(struct decomp));
+ } while (1);
+
+ return 0;
+}
+
+static size_t report__zstd_decompress(struct perf_session *session,
+ void *src, size_t src_size,
+ void *dst, size_t dst_size)
+{
+ size_t ret;
+ ZSTD_inBuffer input = { src, src_size, 0 };
+ ZSTD_outBuffer output = { dst, dst_size, 0 };
+
+ if (session->zstd_dstream == NULL)
+ return 0;
+
+ while (input.pos < input.size) {
+ ret = ZSTD_decompressStream(session->zstd_dstream, ,
);
+ if (ZSTD_isError(ret))
+ {
+ pr_err("failed to decompress (B): %ld -> %ld : %s\n",
+ src_size, output.size, ZSTD_getErrorName(ret));
+ break;
+ }
+ output.dst = dst + output.pos;
+ output.size = dst_size - output.pos;
+ }
+
+ return output.pos;
+}
+
+#else /* !HAVE_ZSTD_SUPPORT */
+static int report__zstd_init(struct perf_session *session __maybe_unused)
+{
+ return -1;
+}
+
+static int report__zstd_fini(struct perf_session *session __maybe_unused)
+{
+ return 0;
+}
+
+static size_t report__zstd_decompress(struct perf_session *session
__maybe_unused,
+ void *src __maybe_unused, size_t src_size
__maybe_unused,
+ void *dst __maybe_unused, size_t dst_size
__maybe_unused)
+{
+ return 0;
+}
+#endif
+
static int hist_iter__report_callback(struct hist_entry_iter *iter,
struct addr_location *al, bool single,
void *arg)
@@ -225,6 +316,57 @@ static int process_feature_event(struct perf_session
*session,
return 0;
}
+static int process_compressed_event(struct perf_session *session,
+ union perf_event *event, u64 file_offset)
+{
+ void *src;
+ size_t decomp_size, src_size;
+ u64 decomp_last_rem = 0;
+ size_t decomp_len = session->header.env.comp_mmap_len;
+ struct decomp *decomp, *decomp_last = session->decomp_last;
+
+ decomp = mmap(NULL, sizeof(struct decomp) + decomp_len,
PROT_READ|PROT_WRITE,
+ MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
+ if (decomp == MAP_FAILED) {
+ pr_err("Couldn't allocate memory for decompression\n");
+ return -1;
+ }
+
+ decomp->file_pos = file_offset;
+ decomp->head = 0;
+
+ if (decomp_last) {
+ decomp_last_rem = decomp_last->size - decomp_last->head;
+ memcpy(decomp->data, &(decomp_last->data[decomp_last->head]),
[PATCH v1 3/4] perf record: enable runtime trace compression
Compression is implemented using Zstandard API and employs AIO buffers
as the memory to operate on so memcpy() is substituted by the API call.
If the API call fails for some reason copying falls back to memcpy().
Data chunks are split and packed into PERF_RECORD_COMPRESSED records by
64KB at max. mmap-flush option value can be used to avoid compression of
every single byte of data and increase compression ratio.
Signed-off-by: Alexey Budankov
---
tools/perf/builtin-record.c | 122 ++--
tools/perf/util/mmap.c | 13 ++--
tools/perf/util/mmap.h | 2 +
3 files changed, 127 insertions(+), 10 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index cb0b880281d7..0ef1878967f8 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -53,6 +53,9 @@
#include
#include
#include
+#ifdef HAVE_ZSTD_SUPPORT
+#include
+#endif
struct switch_output {
bool enabled;
@@ -83,6 +86,9 @@ struct record {
unsigned long long samples;
u64 bytes_transferred;
u64 bytes_compressed;
+#ifdef HAVE_ZSTD_SUPPORT
+ ZSTD_CStream*zstd_cstream;
+#endif
};
static volatile int auxtrace_record__snapshot_started;
@@ -358,6 +364,109 @@ static int record__mmap_flush_parse(const struct option
*opt,
return 0;
}
+#ifdef HAVE_ZSTD_SUPPORT
+static int record__zstd_init(struct record *rec)
+{
+ size_t ret;
+
+ if (rec->opts.comp_level == 0)
+ return 0;
+
+ rec->zstd_cstream = ZSTD_createCStream();
+ if (rec->zstd_cstream == NULL) {
+ pr_err("Couldn't create compression stream, disables trace
compression\n");
+ return -1;
+ }
+
+ ret = ZSTD_initCStream(rec->zstd_cstream, rec->opts.comp_level);
+ if (ZSTD_isError(ret)) {
+ pr_err("Failed to initialize compression stream: %s\n",
ZSTD_getErrorName(ret));
+ return -1;
+ }
+
+ return 0;
+}
+
+static int record__zstd_fini(struct record *rec)
+{
+ if (rec->zstd_cstream) {
+ ZSTD_freeCStream(rec->zstd_cstream);
+ rec->zstd_cstream = NULL;
+ }
+
+ return 0;
+}
+
+static size_t record__zstd_compress(void *to, void *dst, size_t dst_size,
+ void *src, size_t src_size)
+{
+ void *dst_head = dst;
+ struct record *rec = to;
+ size_t ret, size, compressed = 0;
+ struct compressed_event *event = NULL;
+ /* maximum size of record data size (2^16 - 1 - header) */
+ const size_t max_data_size = (1 << 8 * sizeof(event->header.size)) -
+ 1 - sizeof(struct compressed_event);
+ ZSTD_inBuffer input = { src, src_size, 0 };
+ ZSTD_outBuffer output;
+
+ if (rec->opts.comp_level == 0) {
+ memcpy(dst_head, src, src_size);
+ return src_size;
+ }
+
+ while (input.pos < input.size) {
+ event = dst;
+
+ event->header.type = PERF_RECORD_COMPRESSED;
+ event->header.size = size = sizeof(struct compressed_event);
+ compressed += size;
+ dst += size;
+ dst_size -= size;
+
+ output = (ZSTD_outBuffer){ dst, (dst_size > max_data_size) ?
+ max_data_size : dst_size, 0 };
+ ret = ZSTD_compressStream(rec->zstd_cstream, , );
+ ZSTD_flushStream(rec->zstd_cstream, );
+ if (ZSTD_isError(ret)) {
+ pr_err("failed to compress %ld bytes: %s\n",
+ (long)src_size, ZSTD_getErrorName(ret));
+ memcpy(dst_head, src, src_size);
+ return src_size;
+ }
+ size = output.pos;
+
+ event->header.size += size;
+ compressed += size;
+ dst += size;
+ dst_size -= size;
+ }
+
+ rec->bytes_transferred += src_size;
+ rec->bytes_compressed += compressed;
+
+ return compressed;
+}
+#else /* !HAVE_ZSTD_SUPPORT */
+static int record__zstd_init(struct record *rec __maybe_unused)
+{
+ return -1;
+}
+
+static int record__zstd_fini(struct record *rec __maybe_unused)
+{
+ return 0;
+}
+
+static size_t record__zstd_compress(void *to __maybe_unused,
+ void *dst, size_t dst_size __maybe_unused,
+ void *src, size_t src_size)
+{
+ memcpy(dst, src, src_size);
+ return src_size;
+}
+#endif
+
static int process_synthesized_event(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample __maybe_unused,
@@ -799,7 +908,8 @@ static int record__mmap_read_evlist(struct record
[PATCH v1 2/4] perf record: introduce z, mmap-flush options and PERF_RECORD_COMPRESSED record
Introduce --compression_level=n, --mmap-flush options and
PERF_RECORD_COMPRESSED
event record that contains compressed parts of mmap kernel buffer data.
Signed-off-by: Alexey Budankov
---
tools/perf/Documentation/perf-record.txt | 11 +++
tools/perf/builtin-record.c | 97
tools/perf/perf.h| 2 +
tools/perf/util/env.h| 10 +++
tools/perf/util/event.c | 1 +
tools/perf/util/event.h | 7 ++
tools/perf/util/evlist.c | 6 +-
tools/perf/util/evlist.h | 2 +-
tools/perf/util/header.c | 47 +++-
tools/perf/util/header.h | 1 +
tools/perf/util/mmap.c | 4 +-
tools/perf/util/mmap.h | 3 +-
12 files changed, 169 insertions(+), 22 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index d232b13ea713..b849dfdefefe 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -440,6 +440,17 @@ Use control blocks in asynchronous (Posix AIO) trace
writing mode (default:
Asynchronous mode is supported only when linking Perf tool with libc library
providing implementation for Posix AIO API.
+-z::
+--compression-level=n::
+Produce compressed trace file to save storage space using specified level n
(default: 0,
+best speed: 1, best compression: 22). Compression can be activated in
asynchronous trace
+writing mode (--aio) only.
+
+--mmap-flush=n::
+Minimal number of bytes accumulated in mmap buffer that is flushed to trace
file (default: 1).
+When compression mode (-z) is enabled it is recommended to set --mmap-flush to
4096 or more.
+Maximal allowed value is a quater of mmap kernel buffer size.
+
--all-kernel::
Configure all used events to run in kernel space.
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 882285fb9f64..cb0b880281d7 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -81,6 +81,8 @@ struct record {
booltimestamp_boundary;
struct switch_outputswitch_output;
unsigned long long samples;
+ u64 bytes_transferred;
+ u64 bytes_compressed;
};
static volatile int auxtrace_record__snapshot_started;
@@ -286,13 +288,17 @@ static int record__aio_parse(const struct option *opt,
if (unset) {
opts->nr_cblocks = 0;
- } else {
- if (str)
- opts->nr_cblocks = strtol(str, NULL, 0);
- if (!opts->nr_cblocks)
- opts->nr_cblocks = nr_cblocks_default;
+ return 0;
}
+ if (str)
+ opts->nr_cblocks = strtol(str, NULL, 0);
+ if (!opts->nr_cblocks)
+ opts->nr_cblocks = nr_cblocks_default;
+
+ if (opts->nr_cblocks > nr_cblocks_max)
+ opts->nr_cblocks = nr_cblocks_max;
+
return 0;
}
#else /* HAVE_AIO_SUPPORT */
@@ -328,6 +334,30 @@ static int record__aio_enabled(struct record *rec)
return rec->opts.nr_cblocks > 0;
}
+#define MMAP_FLUSH_DEFAULT 1
+
+static int record__mmap_flush_parse(const struct option *opt,
+ const char *str,
+ int unset)
+{
+ int mmap_len;
+ struct record_opts *opts = (struct record_opts *)opt->value;
+
+ if (unset)
+ return 0;
+
+ if (str)
+ opts->mmap_flush = strtol(str, NULL, 0);
+ if (!opts->mmap_flush)
+ opts->mmap_flush = MMAP_FLUSH_DEFAULT;
+
+ mmap_len = perf_evlist__mmap_size(opts->mmap_pages);
+ if (opts->mmap_flush > mmap_len / 4 )
+ opts->mmap_flush = mmap_len / 4;
+
+ return 0;
+}
+
static int process_synthesized_event(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample __maybe_unused,
@@ -533,7 +563,8 @@ static int record__mmap_evlist(struct record *rec,
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
opts->auxtrace_mmap_pages,
-opts->auxtrace_snapshot_mode,
opts->nr_cblocks) < 0) {
+opts->auxtrace_snapshot_mode,
+opts->nr_cblocks, opts->mmap_flush) < 0) {
if (errno == EPERM) {
pr_err("Permission error mapping pages.\n"
"Consider increasing "
@@ -723,7 +754,7 @@ static struct perf_event_header finished_round_event = {
};
static int record__mmap_read_evlist(struct record *rec, struct perf_evlist
*evlist,
- bool overwrite)
+ bool overwrite, bool
[PATCH v1 1/4] feature: build libzstd feature check, LIBZSTD_DIR and NO_LIBZSTD defines
Build feature check, LIBZSTD_DIR and NO_LIBZSTD defines to have capability
of overriding ZStandard library source and disabling of the feature and from
the command line:
$ make -C tools/perf LIBZSTD_DIR=/root/abudanko/zstd-1.3.7 clean all
$ make -C tools/perf NO_LIBZSTD=1 clean all
Signed-off-by: Alexey Budankov
---
tools/build/Makefile.feature | 6 --
tools/build/feature/Makefile | 6 +-
tools/build/feature/test-all.c | 5 +
tools/build/feature/test-libzstd.c | 12
tools/perf/Makefile.config | 20
tools/perf/Makefile.perf | 3 +++
6 files changed, 49 insertions(+), 3 deletions(-)
create mode 100644 tools/build/feature/test-libzstd.c
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 5467c6bf9ceb..25088c8f05b2 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -71,7 +71,8 @@ FEATURE_TESTS_BASIC := \
sdt\
setns \
libopencsd \
-libaio
+libaio \
+libzstd
# FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list
# of all feature tests
@@ -118,7 +119,8 @@ FEATURE_DISPLAY ?= \
lzma \
get_cpuid \
bpf \
- libaio
+ libaio\
+ libzstd
# Set FEATURE_CHECK_(C|LD)FLAGS-all for all FEATURE_TESTS features.
# If in the future we need per-feature checks/flags for features not
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 7ceb4441b627..4b8244ee65ce 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -62,7 +62,8 @@ FILES= \
test-clang.bin\
test-llvm.bin \
test-llvm-version.bin \
- test-libaio.bin
+ test-libaio.bin \
+ test-libzstd.bin
FILES := $(addprefix $(OUTPUT),$(FILES))
@@ -301,6 +302,9 @@ $(OUTPUT)test-clang.bin:
$(OUTPUT)test-libaio.bin:
$(BUILD) -lrt
+$(OUTPUT)test-libzstd.bin:
+ $(BUILD) -lzstd
+
###
clean:
diff --git a/tools/build/feature/test-all.c b/tools/build/feature/test-all.c
index 20cdaa4fc112..5af329b6ffef 100644
--- a/tools/build/feature/test-all.c
+++ b/tools/build/feature/test-all.c
@@ -178,6 +178,10 @@
# include "test-libaio.c"
#undef main
+#define main main_test_zstd
+# include "test-libzstd.c"
+#undef main
+
int main(int argc, char *argv[])
{
main_test_libpython();
@@ -219,6 +223,7 @@ int main(int argc, char *argv[])
main_test_setns();
main_test_libopencsd();
main_test_libaio();
+ main_test_libzstd();
return 0;
}
diff --git a/tools/build/feature/test-libzstd.c
b/tools/build/feature/test-libzstd.c
new file mode 100644
index ..55268c01b84d
--- /dev/null
+++ b/tools/build/feature/test-libzstd.c
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+
+int main(void)
+{
+ ZSTD_CStream*cstream;
+
+ cstream = ZSTD_createCStream();
+ ZSTD_freeCStream(cstream);
+
+ return 0;
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index b441c88cafa1..1dccd776a4aa 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -145,6 +145,13 @@ endif
FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS)
FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS)
-lbabeltrace-ctf
+ifdef LIBZSTD_DIR
+ LIBZSTD_CFLAGS := -I$(LIBZSTD_DIR)/lib
+ LIBZSTD_LDFLAGS := -L$(LIBZSTD_DIR)/lib
+endif
+FEATURE_CHECK_CFLAGS-libzstd := $(LIBZSTD_CFLAGS)
+FEATURE_CHECK_LDFLAGS-libzstd := $(LIBZSTD_LDFLAGS)
+
FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include
-I$(srctree)/tools/arch/$(SRCARCH)/include/uapi -I$(srctree)/tools/include/uapi
# include ARCH specific config
-include $(src-perf)/arch/$(SRCARCH)/Makefile
@@ -770,6 +777,19 @@ ifndef NO_LZMA
endif
endif
+ifndef NO_LIBZSTD
+ ifeq ($(feature-libzstd), 1)
+CFLAGS += -DHAVE_ZSTD_SUPPORT
+CFLAGS += $(LIBZSTD_CFLAGS)
+LDFLAGS += $(LIBZSTD_LDFLAGS)
+EXTLIBS += -lzstd
+$(call detected,CONFIG_ZSTD)
+ else
+msg := $(warning No libzstd found, disables trace compression, please
install libzstd-dev[el] and/or set LIBZSTD_DIR);
+NO_LIBZSTD := 1
+ endif
+endif
+
ifndef NO_BACKTRACE
ifeq ($(feature-backtrace), 1)
CFLAGS += -DHAVE_BACKTRACE_SUPPORT
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index bd23e3f30895..dcac562e1d00 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -108,6 +108,9 @@ include ../scripts/utilities.mak
# streaming for record mode. Currently Posix AIO trace
[PATCH v5 9/9] xen/privcmd-buf.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Boris Ostrovsky
---
drivers/xen/privcmd-buf.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/xen/privcmd-buf.c b/drivers/xen/privcmd-buf.c
index df1ed37..d31b837 100644
--- a/drivers/xen/privcmd-buf.c
+++ b/drivers/xen/privcmd-buf.c
@@ -180,12 +180,8 @@ static int privcmd_buf_mmap(struct file *file, struct
vm_area_struct *vma)
if (vma_priv->n_pages != count)
ret = -ENOMEM;
else
- for (i = 0; i < vma_priv->n_pages; i++) {
- ret = vm_insert_page(vma, vma->vm_start + i * PAGE_SIZE,
-vma_priv->pages[i]);
- if (ret)
- break;
- }
+ ret = vm_insert_range(vma, vma->vm_start, vma_priv->pages,
+ vma_priv->n_pages);
if (ret)
privcmd_buf_vmapriv_free(vma_priv);
--
1.9.1
[PATCH v5 8/9] xen/gntdev.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Boris Ostrovsky
---
drivers/xen/gntdev.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index b0b02a5..430d4cb 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1084,7 +1084,7 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
int index = vma->vm_pgoff;
int count = vma_pages(vma);
struct gntdev_grant_map *map;
- int i, err = -EINVAL;
+ int err = -EINVAL;
if ((vma->vm_flags & VM_WRITE) && !(vma->vm_flags & VM_SHARED))
return -EINVAL;
@@ -1145,12 +1145,9 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
goto out_put_map;
if (!use_ptemod) {
- for (i = 0; i < count; i++) {
- err = vm_insert_page(vma, vma->vm_start + i*PAGE_SIZE,
- map->pages[i]);
- if (err)
- goto out_put_map;
- }
+ err = vm_insert_range(vma, vma->vm_start, map->pages, count);
+ if (err)
+ goto out_put_map;
} else {
#ifdef CONFIG_X86
/*
--
1.9.1
[PATCH v5 7/9] videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range
Convert to use vm_insert_range to map range of kernel memory
to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Acked-by: Marek Szyprowski
Acked-by: Mauro Carvalho Chehab
---
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 015e737..898adef 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -328,28 +328,19 @@ static unsigned int vb2_dma_sg_num_users(void *buf_priv)
static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dma_sg_buf *buf = buf_priv;
- unsigned long uaddr = vma->vm_start;
- unsigned long usize = vma->vm_end - vma->vm_start;
- int i = 0;
+ unsigned long page_count = vma_pages(vma);
+ int err;
if (!buf) {
printk(KERN_ERR "No memory to map\n");
return -EINVAL;
}
- do {
- int ret;
-
- ret = vm_insert_page(vma, uaddr, buf->pages[i++]);
- if (ret) {
- printk(KERN_ERR "Remapping memory, error: %d\n", ret);
- return ret;
- }
-
- uaddr += PAGE_SIZE;
- usize -= PAGE_SIZE;
- } while (usize > 0);
-
+ err = vm_insert_range(vma, vma->vm_start, buf->pages, page_count);
+ if (err) {
+ printk(KERN_ERR "Remapping memory, error: %d\n", err);
+ return err;
+ }
/*
* Use common vm_area operations to track buffer refcount.
--
1.9.1
[PATCH v1 0/4] perf: enable compression of record mode trace to save storage space
The patch set implements runtime record trace compression accompanied by
trace file decompression implemented in the tool report mode. Zstandard
library API [1] is used for compression/decompression of data that come
from perf_events kernel data buffers.
Realized -z,--compression_level=n option provides ~3-5x avg. trace file
size reduction on the tested workloads what significantly saves user's
storage space on larger server systems where trace file size can easily
reach several tens or even hundreds of GiBs, especially when profiling
with stacks for later dwarf unwinding, context-switches tracing and etc.
The option is effective jointly with asynchronous trace writing because
compression requires auxiliary memory buffers to operate on and memory
buffers for asynchronous trace writing serve that purpose.
Added --mmap-flush option can be used to avoid compressing every single
byte of data from mmaped kernel buffers to the trace file and increase
compression ratio at the same time lowering tool runtime overhead.
The feature can be disabled from the command line using NO_LIBZSTD define
and Zstandard sources can be overridden using value of LIBZSTD_DIR define.
The patch set is for Arnaldo's perf/core repository.
Examples:
$ make -C tools/perf NO_LIBZSTD=1 clean all
$ make -C tools/perf LIBZSTD_DIR=/path/to/zstd-1.3.7 clean all
$ tools/perf/perf record -F 42000 --aio -z 1 --mmap-flush 0x1000 -e cycles --
matrix.gcc
Addr of buf1 = 0x7fc1bf183010
Offs of buf1 = 0x7fc1bf183180
Addr of buf2 = 0x7fc1bd182010
Offs of buf2 = 0x7fc1bd1821c0
Addr of buf3 = 0x7fc1bb181010
Offs of buf3 = 0x7fc1bb181100
Addr of buf4 = 0x7fc1b9180010
Offs of buf4 = 0x7fc1b9180140
Threads #: 8 Pthreads
Matrix size: 2048
Using multiply kernel: multiply1
Execution time = 25.499 seconds
[ perf record: Woken up 1157 times to write data ]
[ perf record: Compressed 316.684 MB to 58.034 MB, ratio is 5.457 ]
[ perf record: Captured and wrote 58.059 MB perf.data ]
$ tools/perf/perf report -D --header
#
# captured on: Mon Dec 24 13:19:52 2018
# header version : 1
# data offset: 296
# data size : 60878779
# feat offset: 60879075
# hostname : nntvtune39
# os release : 4.19.9-300.fc29.x86_64
# perf version : 4.13.rc5.gdbb7997
# arch : x86_64
# nrcpus online : 8
# nrcpus avail : 8
# cpudesc : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
# cpuid : GenuineIntel,6,94,3
# total memory : 16153380 kB
# cmdline : /root/abudanko/kernel/acme/tools/perf/perf record -F 42000 --aio
-z 1 --mmap-flush 0x1000 -e cycles -- ../../matrix/linux/matrix.gcc
# event : name = cycles, , id = { 2315, 2316, 2317, 2318, 2319, 2320, 2321,
2322 }, size = 112, { sample_period, sample_freq } = 42000, sample_type =
IP|TID|TIME|PERIOD, read_form>
# CPU_TOPOLOGY info available, use -I to display
# NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: intel_pt = 8, software = 1, power = 11, uprobe = 7,
uncore_imc = 12, cpu = 4, cstate_core = 18, uncore_cbox_2 = 15, breakpoint = 5,
uncore_cbox_0 = 13, tracepoint >
# CACHE info available, use -I to display
# time of first sample : 0.00
# time of last sample : 0.00
# sample duration : 0.000 ms
# MEM_TOPOLOGY info available, use -I to display
# compressed : Zstd, level = 1, ratio = 5
# missing features: TRACING_DATA BUILD_ID BRANCH_STACK GROUP_DESC AUXTRACE
STAT CLOCKID
#
#
0x128 [0x20]: event: 79
.
. ... raw event: size 32 bytes
. : 4f 00 00 00 00 00 20 00 1f 00 00 00 00 00 00 00 O. .
. 0010: 11 a6 ef 1f 00 00 00 00 f8 fe 7c b5 f5 ff ff ff ..|.
0 0x128 [0x20]: PERF_RECORD_TIME_CONV: unhandled!
0x148 [0x50]: event: 1
.
. ... raw event: size 80 bytes
. : 01 00 00 00 01 00 50 00 ff ff ff ff 00 00 00 00 ..P.
. 0010: 00 00 00 a8 ff ff ff ff 00 80 33 18 00 00 00 00 ..3.
. 0020: 00 00 00 a8 ff ff ff ff 5b 6b 65 72 6e 65 6c 2e [kernel.
. 0030: 6b 61 6c 6c 73 79 6d 73 5d 5f 74 65 78 74 00 00 kallsyms]_text..
. 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0 0x148 [0x50]: PERF_RECORD_MMAP -1/0: [0xa800(0x18338000) @
0xa800]: x [kernel.kallsyms]_text
...
0x62d8e [0x8]: event: 68
.
. ... raw event: size 8 bytes
. : 44 00 00 00 00 00 08 00 D...
0 0x62d8e [0x8]: PERF_RECORD_FINISHED_ROUND
0 [0x28]: event: 9
.
. ... raw event: size 40 bytes
. : 09 00 00 00 01 00 28 00 76 78 06 a8 ff ff ff ff ..(.vx..
. 0010: 94 29 00 00 94 29 00 00 82 02 f4 af 33 3e 01 00 .)...)..3>..
. 0020: 01 00 00 00 00 00 00 00
349866692969090 0 [0x28]: PERF_RECORD_SAMPLE(IP, 0x1): 10644/10644:
0xa8067876 period: 1 addr: 0
... thread: perf:10644
.. dso: vmlinux
0
[PATCH v5 6/9] iommu/dma-iommu.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
drivers/iommu/dma-iommu.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d1b0475..de7ffd8 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -622,17 +622,10 @@ struct page **iommu_dma_alloc(struct device *dev, size_t
size, gfp_t gfp,
int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct
*vma)
{
- unsigned long uaddr = vma->vm_start;
- unsigned int i, count = PAGE_ALIGN(size) >> PAGE_SHIFT;
- int ret = -ENXIO;
+ unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
- for (i = vma->vm_pgoff; i < count && uaddr < vma->vm_end; i++) {
- ret = vm_insert_page(vma, uaddr, pages[i]);
- if (ret)
- break;
- uaddr += PAGE_SIZE;
- }
- return ret;
+ return vm_insert_range(vma, vma->vm_start, pages + vma->vm_pgoff,
+ count - vma->vm_pgoff);
}
static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
--
1.9.1
[PATCH v5 5/9] drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 47ff019..c21e5d1 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -225,8 +225,7 @@ struct drm_gem_object *
static int gem_mmap_obj(struct xen_gem_object *xen_obj,
struct vm_area_struct *vma)
{
- unsigned long addr = vma->vm_start;
- int i;
+ int ret;
/*
* clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
@@ -247,18 +246,11 @@ static int gem_mmap_obj(struct xen_gem_object *xen_obj,
* FIXME: as we insert all the pages now then no .fault handler must
* be called, so don't provide one
*/
- for (i = 0; i < xen_obj->num_pages; i++) {
- int ret;
-
- ret = vm_insert_page(vma, addr, xen_obj->pages[i]);
- if (ret < 0) {
- DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
- return ret;
- }
-
- addr += PAGE_SIZE;
- }
- return 0;
+ ret = vm_insert_range(vma, vma->vm_start, xen_obj->pages,
+ xen_obj->num_pages);
+ if (ret < 0)
+ DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
+ return ret;
}
int xen_drm_front_gem_mmap(struct file *filp, struct vm_area_struct *vma)
--
1.9.1
[PATCH v5 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Tested-by: Heiko Stuebner
Acked-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index a8db758..28458ae 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -221,26 +221,18 @@ static int rockchip_drm_gem_object_mmap_iommu(struct
drm_gem_object *obj,
struct vm_area_struct *vma)
{
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
- unsigned int i, count = obj->size >> PAGE_SHIFT;
+ unsigned int count = obj->size >> PAGE_SHIFT;
unsigned long user_count = vma_pages(vma);
- unsigned long uaddr = vma->vm_start;
unsigned long offset = vma->vm_pgoff;
unsigned long end = user_count + offset;
- int ret;
if (user_count == 0)
return -ENXIO;
if (end > count)
return -ENXIO;
- for (i = offset; i < end; i++) {
- ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
- if (ret)
- return ret;
- uaddr += PAGE_SIZE;
- }
-
- return 0;
+ return vm_insert_range(vma, vma->vm_start, rk_obj->pages + offset,
+ user_count);
}
static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
--
1.9.1
[PATCH v5 3/9] drivers/firewire/core-iso.c: Convert to use vm_insert_range
Convert to use vm_insert_range to map range of kernel memory
to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
drivers/firewire/core-iso.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/firewire/core-iso.c b/drivers/firewire/core-iso.c
index 35e784c..7bf28bb 100644
--- a/drivers/firewire/core-iso.c
+++ b/drivers/firewire/core-iso.c
@@ -107,19 +107,8 @@ int fw_iso_buffer_init(struct fw_iso_buffer *buffer,
struct fw_card *card,
int fw_iso_buffer_map_vma(struct fw_iso_buffer *buffer,
struct vm_area_struct *vma)
{
- unsigned long uaddr;
- int i, err;
-
- uaddr = vma->vm_start;
- for (i = 0; i < buffer->page_count; i++) {
- err = vm_insert_page(vma, uaddr, buffer->pages[i]);
- if (err)
- return err;
-
- uaddr += PAGE_SIZE;
- }
-
- return 0;
+ return vm_insert_range(vma, vma->vm_start, buffer->pages,
+ buffer->page_count);
}
void fw_iso_buffer_destroy(struct fw_iso_buffer *buffer,
--
1.9.1
[PATCH v5 2/9] arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
---
arch/arm/mm/dma-mapping.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 661fe48..63467b6 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1582,11 +1582,12 @@ static int __arm_iommu_mmap_attrs(struct device *dev,
struct vm_area_struct *vma
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
- unsigned long uaddr = vma->vm_start;
unsigned long usize = vma->vm_end - vma->vm_start;
+ unsigned long page_count = vma_pages(vma);
struct page **pages = __iommu_get_pages(cpu_addr, attrs);
unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long off = vma->vm_pgoff;
+ int err;
if (!pages)
return -ENXIO;
@@ -1595,18 +1596,11 @@ static int __arm_iommu_mmap_attrs(struct device *dev,
struct vm_area_struct *vma
return -ENXIO;
pages += off;
+ err = vm_insert_range(vma, vma->vm_start, pages, page_count);
+ if (err)
+ pr_err("Remapping memory failed: %d\n", err);
- do {
- int ret = vm_insert_page(vma, uaddr, *pages++);
- if (ret) {
- pr_err("Remapping memory failed: %d\n", ret);
- return ret;
- }
- uaddr += PAGE_SIZE;
- usize -= PAGE_SIZE;
- } while (usize > 0);
-
- return 0;
+ return err;
}
static int arm_iommu_mmap_attrs(struct device *dev,
struct vm_area_struct *vma, void *cpu_addr,
--
1.9.1
[PATCH v5 1/9] mm: Introduce new vm_insert_range API
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
vm_insert_range is the new API which will be used to map a
range of kernel memory/pages to user vma.
This API is tested by Heiko for Rockchip drm driver, on rk3188,
rk3288, rk3328 and rk3399 with graphics.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Mike Rapoport
Reviewed-by: Mauro Carvalho Chehab
Tested-by: Heiko Stuebner
---
include/linux/mm.h | 2 ++
mm/memory.c| 41 +
mm/nommu.c | 7 +++
3 files changed, 50 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index fcf9cc9..2bc399f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2506,6 +2506,8 @@ unsigned long change_prot_numa(struct vm_area_struct *vma,
int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long page_count);
vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn);
vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index 15c417e..d44d4a8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1478,6 +1478,47 @@ static int insert_page(struct vm_area_struct *vma,
unsigned long addr,
}
/**
+ * vm_insert_range - insert range of kernel pages into user vma
+ * @vma: user vma to map to
+ * @addr: target user address of this page
+ * @pages: pointer to array of source kernel pages
+ * @page_count: number of pages need to insert into user vma
+ *
+ * This allows drivers to insert range of kernel pages they've allocated
+ * into a user vma. This is a generic function which drivers can use
+ * rather than using their own way of mapping range of kernel pages into
+ * user vma.
+ *
+ * If we fail to insert any page into the vma, the function will return
+ * immediately leaving any previously-inserted pages present. Callers
+ * from the mmap handler may immediately return the error as their caller
+ * will destroy the vma, removing any successfully-inserted pages. Other
+ * callers should make their own arrangements for calling unmap_region().
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise
+ */
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long page_count)
+{
+ unsigned long uaddr = addr;
+ int ret = 0, i;
+
+ if (page_count > vma_pages(vma))
+ return -ENXIO;
+
+ for (i = 0; i < page_count; i++) {
+ ret = vm_insert_page(vma, uaddr, pages[i]);
+ if (ret < 0)
+ return ret;
+ uaddr += PAGE_SIZE;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(vm_insert_range);
+
+/**
* vm_insert_page - insert single page into user vma
* @vma: user vma to map to
* @addr: target user address of this page
diff --git a/mm/nommu.c b/mm/nommu.c
index 749276b..d6ef5c7 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned
long addr,
}
EXPORT_SYMBOL(vm_insert_page);
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long page_count)
+{
+ return -EINVAL;
+}
+EXPORT_SYMBOL(vm_insert_range);
+
/*
* sys_brk() for the most part doesn't need the global kernel
* lock, except when an application is doing something nasty
--
1.9.1
[PATCH v5 0/9] Use vm_insert_range
v1 -> v2: Address review comment on mm/memory.c. Add EXPORT_SYMBOL for vm_insert_range and corrected the documentation part for this API. In drivers/gpu/drm/xen/xen_drm_front_gem.c, replace err with ret as suggested. In drivers/iommu/dma-iommu.c, handle the scenario of partial mmap() of large buffer by passing *pages + vma->vm_pgoff* to vm_insert_range(). v2 -> v3: Declaration of vm_insert_range() moved to include/linux/mm.h v3 -> v4: Address review comments. In mm/memory.c. Added error check. In arch/arm/mm/dma-mapping.c, remove part of error check as the similar is checked inside vm_insert_range. In rockchip/rockchip_drm_gem.c, vma->vm_pgoff is respected as this might be passed as non zero value considering partial mapping of large buffer. In iommu/dma-iommu.c, count is modifed as (count - vma->vm_pgoff) to handle partial mapping scenario in v2. v4 -> v5: Address review comment on [2/9] and [4/9] In arch/arm/mm/dma-mapping.c, added the error check which was removed in v4, as without those error check we might end up overrun the page array. In rockchip/rockchip_drm_gem.c, added error check which was removed in v1, as without this it might overrun page array. Adjusted page_count parameter before passing it to vm_insert_range(). Souptick Joarder (9): mm: Introduce new vm_insert_range API arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range drivers/firewire/core-iso.c: Convert to use vm_insert_range drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range iommu/dma-iommu.c: Convert to use vm_insert_range videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range xen/gntdev.c: Convert to use vm_insert_range xen/privcmd-buf.c: Convert to use vm_insert_range arch/arm/mm/dma-mapping.c | 18 -- drivers/firewire/core-iso.c | 15 ++--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 14 ++-- drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 --- drivers/iommu/dma-iommu.c | 13 ++- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 - drivers/xen/gntdev.c | 11 +++--- drivers/xen/privcmd-buf.c | 8 ++--- include/linux/mm.h| 2 ++ mm/memory.c | 41 +++ mm/nommu.c| 7 11 files changed, 83 insertions(+), 89 deletions(-) -- 1.9.1
Re: [PATCH] staging: speakup: Fix coding style
Daniel Smith, le lun. 24 déc. 2018 10:12:23 +, a ecrit: > Replaced text ---help--- with help as per style check patch recommendation > > Signed-off-by: Daniel Acked-by: Samuel Thibault
[PATCH] f2fs: fix use-after-free issue with sbi->stat_info
iput() on sbi->node_inode can update sbi->stat_info in the below context, if the f2fs_write_checkpoint() has failed with error. f2fs_balance_fs_bg+0x1ac/0x1ec f2fs_write_node_pages+0x4c/0x260 do_writepages+0x80/0xbc __writeback_single_inode+0xdc/0x4ac writeback_single_inode+0x9c/0x144 write_inode_now+0xc4/0xec iput+0x194/0x22c f2fs_put_super+0x11c/0x1e8 generic_shutdown_super+0x70/0xf4 kill_block_super+0x2c/0x5c kill_f2fs_super+0x44/0x50 deactivate_locked_super+0x60/0x8c deactivate_super+0x68/0x74 cleanup_mnt+0x40/0x78 Fix this by moving f2fs_destroy_stats() further below iput(). Signed-off-by: Sahitya Tummala --- fs/f2fs/super.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index e184ad4e..df41a3a 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -1058,9 +1058,6 @@ static void f2fs_put_super(struct super_block *sb) f2fs_write_checkpoint(sbi, ); } - /* f2fs_write_checkpoint can update stat informaion */ - f2fs_destroy_stats(sbi); - /* * normally superblock is clean, so we need to release this. * In addition, EIO will skip do checkpoint, we need this as well. @@ -1080,6 +1077,12 @@ static void f2fs_put_super(struct super_block *sb) iput(sbi->node_inode); iput(sbi->meta_inode); + /* +* iput() can update stat information, if f2fs_write_checkpoint() +* above failed with error. +*/ + f2fs_destroy_stats(sbi); + /* destroy f2fs internal modules */ f2fs_destroy_node_manager(sbi); f2fs_destroy_segment_manager(sbi); -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v3 9/9] MAINTAINERS: Add maintainer for arm komeda driver
On Mon, Dec 24, 2018 at 1:33 PM Liviu Dudau wrote: > > On Fri, Dec 21, 2018 at 10:01:06AM +, james qian wang (Arm Technology > China) wrote: > > v2: Adjusted the position of KOMEDA by alphabetical order > > > > Signed-off-by: James (Qian) Wang > > Acked-by: Liviu Dudau > > Best regards, > Liviu > > > --- > > MAINTAINERS | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 254b7b267731..e48c2e5fd29f 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -1124,6 +1124,15 @@ S: Supported > > F: drivers/gpu/drm/arm/hdlcd_* > > F: Documentation/devicetree/bindings/display/arm,hdlcd.txt > > > > +ARM KOMEDA DRM-KMS DRIVER > > +M: James (Qian) Wang > > +M: Mali DP Maintainers > > +S: Supported > > +F: drivers/gpu/drm/arm/display/include/ > > +F: drivers/gpu/drm/arm/display/komeda/ > > +F: Documentation/devicetree/bindings/display/arm/arm,komeda.txt > > +F: Documentation/gpu/komeda-kms.rst Mentioning the git tree would be good. And I guess you'll do some kind of group maintainership? Probably still good if you send out a dedicated/topic pull request for this new driver, but from then on it's all in the same git repo. -Daniel > > + > > ARM MALI-DP DRM DRIVER > > M: Liviu Dudau > > M: Brian Starkey > > -- > > 2.17.1 > > > > -- > > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --- > ¯\_(ツ)_/¯ -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [xarray] b803b42823: BUG:soft_lockup-CPU##stuck_for#s
On Mon, Dec 24, 2018 at 08:56:20PM +0800, kernel test robot wrote: > [ 51.886077] Call Trace: > [ 51.886077] ? xas_find+0x11b/0x240 > [ 51.886077] ? xa_find+0xc2/0xe0 > [ 51.886077] ? check_find+0x11a/0x420 > [ 51.886077] ? check_multi_store+0xa40/0xa40 > [ 51.886077] ? xarray_checks+0x30/0x70 > [ 51.886077] ? do_one_initcall+0x68/0x253 Since you're running the selftests at 51 seconds in, I'm putting this in the same bucket as the others -- spurious report due to overloaded test machine.
Re: [PATCH] arm64: dts: rockchip: enable analog audio node for rock64
Hello Heiko, I understand. Thanks a lot! Best Regards, Katsuhiro Suzuki On 2018/12/24 16:16, Heiko Stuebner wrote: Hi, Am Sonntag, 23. Dezember 2018, 11:10:26 CET schrieb Katsuhiro Suzuki: The Rock64 boards has analog audio jack on it. RK3328 can output analog audio signal using I2S1 and ACODEC core. This patch adds sound node for analog audio for Rock64. Signed-off-by: Katsuhiro Suzuki I've put a patch collecting the sound-dai-cells in rk3328.dtsi before this one, dropped the sound-dai-cells from here and applied the patch for 4.22. Thanks Heiko
Incorrect use IPCB in icmp_send code
Hello! icmp_send routine calls ip_option_echo, which uses IPCB to take skbuff compiled IP options. But icmp_send could be called from TCP level too (security_sock_rcv_skb - cipso_v4_error for INET stream connection, for example). After moving IP header data to the end of the struct tcp_skb_cb, this could lead to memory corruption when IP options copying. Thanks.
[xarray] b803b42823: BUG:soft_lockup-CPU##stuck_for#s
FYI, we noticed the following commit (built with gcc-4.9):
commit: b803b42823d0d9e8b6deccf01ffc2aba5d0738df ("xarray: Add XArray
iterators")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 768M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+---+++
| | 41aec91f55 |
b803b42823 |
+---+++
| boot_successes| 18 |
5 |
| boot_failures | 2 |
17 |
| WARNING:at_drivers/ata/libata-core.c:#ata_host_detach[libata] | 2 |
4 |
| EIP:ata_host_detach | 2 |
4 |
| BUG:soft_lockup-CPU##stuck_for#s | 0 |
13 |
| EIP:lock_is_held_type | 0 |
9 |
| Kernel_panic-not_syncing:softlockup:hung_tasks| 0 |
13 |
| EIP:lock_release | 0 |
1 |
| EIP:xas_find | 0 |
1 |
| EIP:lock_acquire | 0 |
2 |
+---+++
[ 51.886077] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper:1]
[ 51.886077] Modules linked in:
[ 51.886077] irq event stamp: 2387290
[ 51.886077] hardirqs last enabled at (2387289): [<8ae9ab9d>]
__call_rcu+0x7d/0xa0
[ 51.886077] hardirqs last disabled at (2387290): [<8ae015a9>]
trace_hardirqs_off_thunk+0xc/0x13
[ 51.886077] softirqs last enabled at (2387276): [<8b69352d>]
__do_softirq+0x31d/0x34f
[ 51.886077] softirqs last disabled at (2387269): [<8ae1880c>]
do_softirq_own_stack+0x1c/0x30
[ 51.886077] CPU: 0 PID: 1 Comm: swapper Not tainted
4.19.0-rc5-00251-gb803b42 #1
[ 51.886077] EIP: lock_is_held_type+0xb3/0xf0
[ 51.886077] Code: c1 e1 05 31 db 29 c1 8a 84 0e fe 03 00 00 83 e0 03 39 c2
0f 94 c3 a1 20 31 a8 8b c7 80 e4 03 00 00 00 00 00 00 8b 45 ec 50 9d <66> 66 66
90 83 c4 0c 89 d8 5b 5e 5f 5d c3 8d b4 26 00 00 00 00 31
[ 51.886077] EAX: 00200246 EBX: ECX: 781103e8 EDX: 8bab9bd0
[ 51.886077] ESI: 0001 EDI: 7811 EBP: 78105ec0 ESP: 78105ea8
[ 51.886077] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00200246
[ 51.886077] CR0: 80050033 CR2: CR3: 13c12000 CR4: 06d0
[ 51.886077] Call Trace:
[ 51.886077] ? xas_find+0x11b/0x240
[ 51.886077] ? xa_find+0xc2/0xe0
[ 51.886077] ? check_find+0x11a/0x420
[ 51.886077] ? check_multi_store+0xa40/0xa40
[ 51.886077] ? xarray_checks+0x30/0x70
[ 51.886077] ? do_one_initcall+0x68/0x253
[ 51.886077] ? parse_args+0x18a/0x2d0
[ 51.886077] ? rcu_read_lock_sched_held+0x33/0x70
[ 51.886077] ? trace_initcall_level+0x57/0x8d
[ 51.886077] ? kernel_init_freeable+0x164/0x232
[ 51.886077] ? rest_init+0xb0/0xb0
[ 51.886077] ? kernel_init+0x8/0xf0
[ 51.886077] ? ret_from_fork+0x19/0x30
[ 51.886077] Kernel panic - not syncing: softlockup: hung tasks
[ 51.886077] CPU: 0 PID: 1 Comm: swapper Tainted: G L
4.19.0-rc5-00251-gb803b42 #1
[ 51.886077] Call Trace:
[ 51.886077] ? dump_stack+0x16/0x26
[ 51.886077] ? panic+0x8b/0x1c8
[ 51.886077] ? watchdog_timer_fn+0x24a/0x250
[ 51.886077] ? __lockup_detector_cleanup+0x30/0x30
[ 51.886077] ? __hrtimer_run_queues+0x17c/0x3b0
[ 51.886077] ? __lockup_detector_cleanup+0x30/0x30
[ 51.886077] ? hrtimer_run_queues+0x8c/0xe0
[ 51.886077] ? run_local_timers+0x8/0x30
[ 51.886077] ? update_process_times+0x17/0x40
[ 51.886077] ? tick_periodic+0x29/0xc0
[ 51.886077] ? tick_handle_periodic+0x13/0x60
[ 51.886077] ? smp_apic_timer_interrupt+0x77/0x1b0
[ 51.886077] ? apic_timer_interrupt+0xd6/0xe0
[ 51.886077] ? printk+0x5/0x10
[ 51.886077] ? lock_is_held_type+0xb3/0xf0
[ 51.886077] ? xas_find+0x11b/0x240
[ 51.886077] ? xa_find+0xc2/0xe0
[ 51.886077] ? check_find+0x11a/0x420
[ 51.886077] ? check_multi_store+0xa40/0xa40
[ 51.886077] ? xarray_checks+0x30/0x70
[ 51.886077] ? do_one_initcall+0x68/0x253
[ 51.886077] ? parse_args+0x18a/0x2d0
[ 51.886077] ? rcu_read_lock_sched_held+0x33/0x70
[ 51.886077] ? trace_initcall_level+0x57/0x8d
[ 51.886077] ? kernel_init_freeable+0x164/0x232
[ 51.886077] ?
Re: [PATCH v3 8/9] drm/doc: Add initial komeda driver documentation
On Fri, Dec 21, 2018 at 10:00:49AM +, james qian wang (Arm Technology China) wrote: > v2: Some editing changes according to Randy Dunlap's comments > > Signed-off-by: James (Qian) Wang Reviewed-by: Liviu Dudau > --- > Documentation/gpu/drivers.rst| 1 + > Documentation/gpu/komeda-kms.rst | 488 +++ > 2 files changed, 489 insertions(+) > create mode 100644 Documentation/gpu/komeda-kms.rst > > diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst > index 7c1672118a73..978e6da9bbff 100644 > --- a/Documentation/gpu/drivers.rst > +++ b/Documentation/gpu/drivers.rst > @@ -17,6 +17,7 @@ GPU Driver Documentation > vkms > bridge/dw-hdmi > xen-front > + komeda-kms > > .. only:: subproject and html > > diff --git a/Documentation/gpu/komeda-kms.rst > b/Documentation/gpu/komeda-kms.rst > new file mode 100644 > index ..b08da1cffecc > --- /dev/null > +++ b/Documentation/gpu/komeda-kms.rst > @@ -0,0 +1,488 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +== > + drm/komeda Arm display driver > +== > + > +The drm/komeda driver supports the Arm display processor D71 and later > products, > +this document gives a brief overview of driver design: how it works and why > +design it like that. > + > +Overview of D71 like display IPs > + > + > +From D71, Arm display IP begins to adopt a flexible and modularized > +architecture. A display pipeline is made up of multiple individual and > +functional pipeline stages called components, and every component has some > +specific capabilities that can give the flowed pipeline pixel data a > +particular processing. > + > +Typical D71 components: > + > +Layer > +- > +Layer is the first pipeline stage, which prepares the pixel data for the next > +stage. It fetches the pixel from memory, decodes it if it's AFBC, rotates the > +source image, unpacks or converts YUV pixels to the device internal RGB > pixels, > +then adjusts the color_space of pixels if needed. > + > +Scaler > +-- > +As its name suggests, scaler takes responsibility for scaling, and D71 also > +supports image enhancements by scaler. > +The usage of scaler is very flexible and can be connected to layer output > +for layer scaling, or connected to compositor and scale the whole display > +frame and then feed the output data into wb_layer which will then write it > +into memory. > + > +Compositor (compiz) > +--- > +Compositor blends multiple layers or pixel data flows into one single display > +frame. its output frame can be fed into post image processor for showing it > on > +the monitor or fed into wb_layer and written to memory at the same time. > +user can also insert a scaler between compositor and wb_layer to down scale > +the display frame first and and then write to memory. > + > +Writeback Layer (wb_layer) > +-- > +Writeback layer does the opposite things of Layer, which connects to compiz > +and writes the composition result to memory. > + > +Post image processor (improc) > +- > +Post image processor adjusts frame data like gamma and color space to fit the > +requirements of the monitor. > + > +Timing controller (timing_ctrlr) > + > +Final stage of display pipeline, Timing controller is not for the pixel > +handling, but only for controlling the display timing. > + > +Merger > +-- > +D71 scaler mostly only has the half horizontal input/output capabilities > +compared with Layer, like if Layer supports 4K input size, the scaler only > can > +support 2K input/output in the same time. To achieve the ful frame scaling, > D71 > +introduces Layer Split, which splits the whole image to two half parts and > feeds > +them to two Layers A and B, and does the scaling independently. After scaling > +the result need to be fed to merger to merge two part images together, and > then > +output merged result to compiz. > + > +Splitter > + > +Similar to Layer Split, but Splitter is used for writeback, which splits the > +compiz result to two parts and then feed them to two scalers. > + > +Possible D71 Pipeline usage > +=== > + > +Benefitting from the modularized architecture, D71 pipelines can be easily > +adjusted to fit different usages. And D71 has two pipelines, which support > two > +types of working mode: > + > +- Dual display mode > +Two pipelines work independently and separately to drive two display > outputs. > + > +- Single display mode > +Two pipelines work together to drive only one display output. > + > +On this mode, pipeline_B doesn't work indenpendently, but outputs its > +composition result into pipeline_A, and its pixel timing also derived > from > +pipeline_A.timing_ctrlr. The pipeline_B works just like a "slave" of > +pipeline_A(master) > + > +Single
Re: [PATCH v3 9/9] MAINTAINERS: Add maintainer for arm komeda driver
On Fri, Dec 21, 2018 at 10:01:06AM +, james qian wang (Arm Technology China) wrote: > v2: Adjusted the position of KOMEDA by alphabetical order > > Signed-off-by: James (Qian) Wang Acked-by: Liviu Dudau Best regards, Liviu > --- > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 254b7b267731..e48c2e5fd29f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1124,6 +1124,15 @@ S: Supported > F: drivers/gpu/drm/arm/hdlcd_* > F: Documentation/devicetree/bindings/display/arm,hdlcd.txt > > +ARM KOMEDA DRM-KMS DRIVER > +M: James (Qian) Wang > +M: Mali DP Maintainers > +S: Supported > +F: drivers/gpu/drm/arm/display/include/ > +F: drivers/gpu/drm/arm/display/komeda/ > +F: Documentation/devicetree/bindings/display/arm/arm,komeda.txt > +F: Documentation/gpu/komeda-kms.rst > + > ARM MALI-DP DRM DRIVER > M: Liviu Dudau > M: Brian Starkey > -- > 2.17.1 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH v3 7/9] drm/komeda: Attach komeda_dev to DRM-KMS
On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology
China) wrote:
> Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> CRTC: according to the komeda_pipeline
> PLANE: according to komeda_layer (layer input pipeline)
> PRIVATE_OBJS: komeda_pipeline/component all will be treat as private_objs
>
> komeda_kms is for connecting DRM-KMS and komeda_dev, like reporting the
> kms object properties according to the komeda_dev, and pass/convert KMS's
> requirement to komeda_dev.
>
> Changes in v3:
> - Fixed style problem found by checkpatch.pl --strict.
>
> Changes in v2:
> - Unified abbreviation of "pipeline" to "pipe".
>
> Signed-off-by: James (Qian) Wang
> ---
> drivers/gpu/drm/arm/display/komeda/Makefile | 6 +-
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 106 +++
> .../gpu/drm/arm/display/komeda/komeda_drv.c | 19 +-
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 169 ++
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 113
> .../drm/arm/display/komeda/komeda_pipeline.h | 3 +
> .../gpu/drm/arm/display/komeda/komeda_plane.c | 109 +++
> .../arm/display/komeda/komeda_private_obj.c | 88 +
> 8 files changed, 608 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
> b/drivers/gpu/drm/arm/display/komeda/Makefile
> index 25beae900ed2..1b875e5dc0f6 100644
> --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> @@ -9,7 +9,11 @@ komeda-y := \
> komeda_dev.o \
> komeda_format_caps.o \
> komeda_pipeline.o \
> - komeda_framebuffer.o
> + komeda_framebuffer.o \
> + komeda_kms.o \
> + komeda_crtc.o \
> + komeda_plane.o \
> + komeda_private_obj.o
>
> komeda-y += \
> d71/d71_dev.o
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> new file mode 100644
> index ..5bb5a55f6b31
> --- /dev/null
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> + * Author: James.Qian.Wang
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "komeda_dev.h"
> +#include "komeda_kms.h"
> +
> +struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
> +};
> +
> +static const struct drm_crtc_funcs komeda_crtc_funcs = {
> +};
> +
> +int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> +struct komeda_dev *mdev)
> +{
> + struct komeda_crtc *crtc;
> + struct komeda_pipeline *master;
> + char str[16];
> + int i;
> +
> + kms->n_crtcs = 0;
> +
> + for (i = 0; i < mdev->n_pipelines; i++) {
> + crtc = >crtcs[kms->n_crtcs];
> + master = mdev->pipelines[i];
> +
> + crtc->master = master;
> + crtc->slave = NULL;
> +
> + if (crtc->slave)
> + sprintf(str, "pipe-%d", crtc->slave->id);
> + else
> + sprintf(str, "None");
> +
> + DRM_INFO("crtc%d: master(pipe-%d) slave(%s) output: %s.\n",
> + kms->n_crtcs, master->id, str,
> + master->of_output_dev ?
> + master->of_output_dev->full_name : "None");
> +
> + kms->n_crtcs++;
> + }
> +
> + return 0;
> +}
> +
> +static struct drm_plane *
> +get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> +{
> + struct komeda_plane *kplane;
> + struct drm_plane *plane;
> +
> + drm_for_each_plane(plane, >base) {
> + if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> + continue;
> +
> + kplane = to_kplane(plane);
> + /* only master can be primary */
> + if (kplane->layer->base.pipeline == crtc->master)
> + return plane;
> + }
> +
> + return NULL;
> +}
> +
> +static int komeda_crtc_add(struct komeda_kms_dev *kms,
> +struct komeda_crtc *kcrtc)
> +{
> + struct drm_crtc *crtc = >base;
> + int err;
> +
> + err = drm_crtc_init_with_planes(>base, crtc,
> + get_crtc_primary(kms, kcrtc), NULL,
> + _crtc_funcs, NULL);
> + if (err)
> + return err;
> +
> + drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> + drm_crtc_vblank_reset(crtc);
> +
> + crtc->port =
[PATCH v2 4/4] perf record: implement --affinity=node|cpu option
Implement --affinity=node|cpu option for the record mode defaulting
to system affinity mask bouncing.
Signed-off-by: Alexey Budankov
---
tools/perf/Documentation/perf-record.txt | 5 +
tools/perf/builtin-record.c | 18 ++
2 files changed, 23 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index d232b13ea713..efb839784f32 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -440,6 +440,11 @@ Use control blocks in asynchronous (Posix AIO) trace
writing mode (default:
Asynchronous mode is supported only when linking Perf tool with libc library
providing implementation for Posix AIO API.
+--affinity=mode::
+Set affinity mask of trace reading thread according to the policy defined by
'mode' value:
+ node - thread affinity mask is set to NUMA node cpu mask of the processed
mmap buffer
+ cpu - thread affinity mask is set to cpu of the processed mmap buffer
+
--all-kernel::
Configure all used events to run in kernel space.
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index eea96794ee45..57dc3a45d16f 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1653,6 +1653,21 @@ static int parse_clockid(const struct option *opt, const
char *str, int unset)
ui__warning("unknown clockid %s, check man page\n", ostr);
return -1;
}
+static int record__parse_affinity(const struct option *opt, const char *str,
int unset)
+{
+ struct record_opts *opts = (struct record_opts *)opt->value;
+
+ if (!unset) {
+ if (str) {
+ if (!strcasecmp(str, "node"))
+ opts->affinity = PERF_AFFINITY_NODE;
+ else if (!strcasecmp(str, "cpu"))
+ opts->affinity = PERF_AFFINITY_CPU;
+ }
+ }
+
+ return 0;
+}
static int record__parse_mmap_pages(const struct option *opt,
const char *str,
@@ -1961,6 +1976,9 @@ static struct option __record_options[] = {
_cblocks_default, "n", "Use control blocks in
asynchronous trace writing mode (default: 1, max: 4)",
record__aio_parse),
#endif
+ OPT_CALLBACK(0, "affinity", , "node|cpu",
+"Set affinity mask of trace reading thread to NUMA node
cpu mask or cpu of processed mmap buffer",
+record__parse_affinity),
OPT_END()
};
[PATCH v2 3/4] perf record: apply affinity masks when reading mmap buffers
Build node cpu masks for mmap data buffers. Apply node cpu
masks to tool thread every time it references data buffers
cross node or cross cpu.
Signed-off-by: Alexey Budankov
---
Changes in v2:
- separated AIO buffers binding to patch 2/4
---
tools/perf/builtin-record.c | 9 +
tools/perf/util/evlist.c| 6 +-
tools/perf/util/mmap.c | 12
tools/perf/util/mmap.h | 1 +
4 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index b26febb54d01..eea96794ee45 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -536,6 +536,9 @@ static int record__mmap_evlist(struct record *rec,
struct record_opts *opts = >opts;
char msg[512];
+ if (opts->affinity != PERF_AFFINITY_SYS)
+ cpu__setup_cpunode_map();
+
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
opts->auxtrace_mmap_pages,
opts->auxtrace_snapshot_mode,
@@ -755,6 +758,12 @@ static int record__mmap_read_evlist(struct record *rec,
struct perf_evlist *evli
struct perf_mmap *map = [i];
if (map->base) {
+ if (rec->opts.affinity != PERF_AFFINITY_SYS &&
+ !CPU_EQUAL(>affinity_mask,
>affinity_mask)) {
+ CPU_ZERO(>affinity_mask);
+ CPU_OR(>affinity_mask,
>affinity_mask, >affinity_mask);
+ sched_setaffinity(0,
sizeof(rec->affinity_mask), >affinity_mask);
+ }
if (!record__aio_enabled(rec)) {
if (perf_mmap__push(map, rec, record__pushfn)
!= 0) {
rc = -1;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 60e825be944a..5ca5bb5ea0db 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1028,7 +1028,11 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
* Its value is decided by evsel's write_backward.
* So should not be passed through const pointer.
*/
- struct mmap_params mp = { .nr_cblocks = nr_cblocks, .affinity =
affinity };
+ struct mmap_params mp = {
+ .nr_cblocks = nr_cblocks,
+ .affinity = affinity,
+ .cpu_map= cpus
+ };
if (!evlist->mmap)
evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index 742fa9a8e498..a2095e4eda4b 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -361,6 +361,7 @@ void perf_mmap__munmap(struct perf_mmap *map)
int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd, int
cpu)
{
+ int c, nr_cpus, node;
/*
* The last one will be done at perf_mmap__consume(), so that we
* make sure we don't prevent tools from consuming every last event in
@@ -389,6 +390,17 @@ int perf_mmap__mmap(struct perf_mmap *map, struct
mmap_params *mp, int fd, int c
map->cpu = cpu;
CPU_ZERO(>affinity_mask);
+ if (mp->affinity == PERF_AFFINITY_NODE && cpu__max_node() > 1) {
+ nr_cpus = cpu_map__nr(mp->cpu_map);
+ node = cpu__get_node(map->cpu);
+ for (c = 0; c < nr_cpus; c++) {
+ if (cpu__get_node(c) == node) {
+ CPU_SET(c, >affinity_mask);
+ }
+ }
+ } else if (mp->affinity == PERF_AFFINITY_CPU) {
+ CPU_SET(map->cpu, >affinity_mask);
+ }
if (auxtrace_mmap__mmap(>auxtrace_mmap,
>auxtrace_mp, map->base, fd))
diff --git a/tools/perf/util/mmap.h b/tools/perf/util/mmap.h
index e566c19b242b..b3f724fad22e 100644
--- a/tools/perf/util/mmap.h
+++ b/tools/perf/util/mmap.h
@@ -72,6 +72,7 @@ enum bkw_mmap_state {
struct mmap_params {
int prot, mask, nr_cblocks, affinity;
struct auxtrace_mmap_params auxtrace_mp;
+ const struct cpu_map*cpu_map;
};
int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd, int
cpu);
Re: [PATCH v4 10/10] sched/fair: Provide idle search schedstats
On 12/06/2018 01:28 PM, Steve Sistare wrote: Add schedstats to measure the effectiveness of searching for idle CPUs and stealing tasks. This is a temporary patch intended for use during development only. SCHEDSTAT_VERSION is bumped to 16, and the following fields are added to the per-CPU statistics of /proc/schedstat: Why only temporary? It would seem that this might be useful information in the future too, for other developers with either new code or new use cases. Rick
[PATCH] drm/vc4: Allow fb modifiers early enough to fill IN_FORMATS property
The KMS mode_config elements are currently configured in vc4_kms_load,
that is called after all components are binded (component_bind_all).
However, the CRTC component (for the Pixel Valve) needs to access the
allow_fb_modifiers element at bind time, when initializing its planes
through drm_universal_plane_init.
This helpers checks allow_fb_modifiers to decide whether to fill the
IN_FORMATS property. Because allow_fb_modifiers is still set to false
at this point, the property is never filled and userspace cannot
retrieve the combination of supported formats and modifiers.
Fix this by setting allow_fb_modifiers right after calling
drm_mode_config_init (which initializes the structure), before binding
the components of the driver.
Fixes: 423ad7b3cbd1 ("drm/vc4: Advertise supported modifiers for planes")
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4_kms.c | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 7195a0bcceb3..5c24f80dd34e 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -273,6 +273,7 @@ static int vc4_drm_bind(struct device *dev)
goto dev_put;
drm_mode_config_init(drm);
+ drm->mode_config.allow_fb_modifiers = true;
vc4_gem_init(drm);
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index b0cbb869f659..b70931fd8cf0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -530,7 +530,6 @@ int vc4_kms_load(struct drm_device *dev)
dev->mode_config.funcs = _mode_funcs;
dev->mode_config.preferred_depth = 24;
dev->mode_config.async_page_flip = true;
- dev->mode_config.allow_fb_modifiers = true;
drm_modeset_lock_init(>ctm_state_lock);
--
2.20.1
[PATCH v2 2/4] perf record: bind the AIO user space buffers to nodes
Allocate and bind AIO user space buffers to the memory nodes
that mmap kernel buffers are bound to.
Signed-off-by: Alexey Budankov
---
Changes in v2:
- implemented perf_mmap__aio_alloc, perf_mmap__aio_free, perf_mmap__aio_bind
and put HAVE_LIBNUMA_SUPPORT #ifdefs in there
---
tools/perf/util/mmap.c | 49 --
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index e68ba754a8e2..742fa9a8e498 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -10,6 +10,9 @@
#include
#include
#include
+#ifdef HAVE_LIBNUMA_SUPPORT
+#include
+#endif
#include "debug.h"
#include "event.h"
#include "mmap.h"
@@ -154,6 +157,46 @@ void __weak auxtrace_mmap_params__set_idx(struct
auxtrace_mmap_params *mp __mayb
}
#ifdef HAVE_AIO_SUPPORT
+
+#ifdef HAVE_LIBNUMA_SUPPORT
+static void perf_mmap__aio_alloc(void **data, size_t len)
+{
+ *data = mmap(NULL, len, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
+}
+
+static void perf_mmap__aio_free(void **data, size_t len)
+{
+ munmap(*data, len);
+ *data = NULL;
+}
+
+static void perf_mmap__aio_bind(void *data, size_t len, int cpu, int affinity)
+{
+ if (affinity != PERF_AFFINITY_SYS && cpu__max_node() > 1) {
+ unsigned long node_mask = 1UL << cpu__get_node(cpu);
+ if (mbind(data, len, MPOL_BIND, _mask, 1, 0)) {
+ pr_debug2("failed to bind [%p-%p] to node %d\n",
+ data, data + len, cpu__get_node(cpu));
+ }
+ }
+}
+#else
+static void perf_mmap__aio_alloc(void **data, size_t len)
+{
+ *data = malloc(len);
+}
+
+static void perf_mmap__aio_free(void **data, size_t len __maybe_unused)
+{
+ zfree(data);
+}
+
+static void perf_mmap__aio_bind(void *data __maybe_unused, size_t len
__maybe_unused,
+int cpu __maybe_unused, int affinity
__maybe_unused)
+{
+}
+#endif
+
static int perf_mmap__aio_mmap(struct perf_mmap *map, struct mmap_params *mp)
{
int delta_max, i, prio;
@@ -177,11 +220,13 @@ static int perf_mmap__aio_mmap(struct perf_mmap *map,
struct mmap_params *mp)
}
delta_max = sysconf(_SC_AIO_PRIO_DELTA_MAX);
for (i = 0; i < map->aio.nr_cblocks; ++i) {
- map->aio.data[i] = malloc(perf_mmap__mmap_len(map));
+ size_t mmap_len = perf_mmap__mmap_len(map);
+ perf_mmap__aio_alloc(&(map->aio.data[i]), mmap_len);
if (!map->aio.data[i]) {
pr_debug2("failed to allocate data buffer area,
error %m");
return -1;
}
+ perf_mmap__aio_bind(map->aio.data[i], mmap_len,
map->cpu, mp->affinity);
/*
* Use cblock.aio_fildes value different from -1
* to denote started aio write operation on the
@@ -210,7 +255,7 @@ static void perf_mmap__aio_munmap(struct perf_mmap *map)
int i;
for (i = 0; i < map->aio.nr_cblocks; ++i)
- zfree(>aio.data[i]);
+ perf_mmap__aio_free(&(map->aio.data[i]),
perf_mmap__mmap_len(map));
if (map->aio.data)
zfree(>aio.data);
zfree(>aio.cblocks);
[PATCH v2 1/4] perf record: allocate affinity masks
Allocate affinity option and masks for mmap data buffers and
record thread as well as initialize allocated objects.
Signed-off-by: Alexey Budankov
---
Changes in v2:
- made debug affinity mode message user friendly
- converted affinity mode defines to enum values
---
tools/perf/builtin-record.c | 13 -
tools/perf/perf.h | 8
tools/perf/util/evlist.c| 6 +++---
tools/perf/util/evlist.h| 2 +-
tools/perf/util/mmap.c | 2 ++
tools/perf/util/mmap.h | 3 ++-
6 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 882285fb9f64..b26febb54d01 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -81,12 +81,17 @@ struct record {
booltimestamp_boundary;
struct switch_outputswitch_output;
unsigned long long samples;
+ cpu_set_t affinity_mask;
};
static volatile int auxtrace_record__snapshot_started;
static DEFINE_TRIGGER(auxtrace_snapshot_trigger);
static DEFINE_TRIGGER(switch_output_trigger);
+static const char* affinity_tags[PERF_AFFINITY_EOF] = {
+ "SYS", "NODE", "CPU"
+};
+
static bool switch_output_signal(struct record *rec)
{
return rec->switch_output.signal &&
@@ -533,7 +538,8 @@ static int record__mmap_evlist(struct record *rec,
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
opts->auxtrace_mmap_pages,
-opts->auxtrace_snapshot_mode,
opts->nr_cblocks) < 0) {
+opts->auxtrace_snapshot_mode,
+opts->nr_cblocks, opts->affinity) < 0) {
if (errno == EPERM) {
pr_err("Permission error mapping pages.\n"
"Consider increasing "
@@ -1980,6 +1986,9 @@ int cmd_record(int argc, const char **argv)
# undef REASON
#endif
+ CPU_ZERO(>affinity_mask);
+ rec->opts.affinity = PERF_AFFINITY_SYS;
+
rec->evlist = perf_evlist__new();
if (rec->evlist == NULL)
return -ENOMEM;
@@ -2143,6 +2152,8 @@ int cmd_record(int argc, const char **argv)
if (verbose > 0)
pr_info("nr_cblocks: %d\n", rec->opts.nr_cblocks);
+ pr_debug("affinity: %s\n", affinity_tags[rec->opts.affinity]);
+
err = __cmd_record(, argc, argv);
out:
perf_evlist__delete(rec->evlist);
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 388c6dd128b8..69f54529d81f 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -83,6 +83,14 @@ struct record_opts {
clockid_tclockid;
u64 clockid_res_ns;
int nr_cblocks;
+ int affinity;
+};
+
+enum perf_affinity {
+ PERF_AFFINITY_SYS = 0,
+ PERF_AFFINITY_NODE,
+ PERF_AFFINITY_CPU,
+ PERF_AFFINITY_EOF
};
struct option;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index e90575192209..60e825be944a 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1018,7 +1018,7 @@ int perf_evlist__parse_mmap_pages(const struct option
*opt, const char *str,
*/
int perf_evlist__mmap_ex(struct perf_evlist *evlist, unsigned int pages,
unsigned int auxtrace_pages,
-bool auxtrace_overwrite, int nr_cblocks)
+bool auxtrace_overwrite, int nr_cblocks, int affinity)
{
struct perf_evsel *evsel;
const struct cpu_map *cpus = evlist->cpus;
@@ -1028,7 +1028,7 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
* Its value is decided by evsel's write_backward.
* So should not be passed through const pointer.
*/
- struct mmap_params mp = { .nr_cblocks = nr_cblocks };
+ struct mmap_params mp = { .nr_cblocks = nr_cblocks, .affinity =
affinity };
if (!evlist->mmap)
evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
@@ -1060,7 +1060,7 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
int perf_evlist__mmap(struct perf_evlist *evlist, unsigned int pages)
{
- return perf_evlist__mmap_ex(evlist, pages, 0, false, 0);
+ return perf_evlist__mmap_ex(evlist, pages, 0, false, 0,
PERF_AFFINITY_SYS);
}
int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 868294491194..72728d7f4432 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -162,7 +162,7 @@ unsigned long perf_event_mlock_kb_in_pages(void);
int perf_evlist__mmap_ex(struct perf_evlist *evlist, unsigned int pages,
unsigned int auxtrace_pages,
-bool auxtrace_overwrite, int nr_cblocks);
+bool auxtrace_overwrite, int nr_cblocks, int
[PATCH v2 0/4] Reduce NUMA related overhead in perf record profiling on large server systems
It has been observed that trace reading thread runs on the same hw thread most of the time during perf record sampling collection. This scheduling layout leads up to 30% profiling overhead in case when some cpu intensive workload fully utilizes a large server system with NUMA. Overhead usually arises from remote (cross node) HW and memory references that have much longer latencies than local ones [1]. This patch set implements --affinity option that lowers 30% overhead completely for serial trace streaming (--affinity=cpu) and from 30% to 10% for AIO1 (--aio=1) trace streaming (--affinity=node|cpu). See OVERHEAD section below for more details. Implemented extension provides users with capability to instruct Perf tool to bounce trace reading thread's affinity mask between NUMA nodes (--affinity=node) or assign the thread to the exact cpu (--affinity=cpu) that trace buffer being processed belongs to. The extension brings improvement in case of full system utilization when Perf tool process contends with workload process on cpu cores. In case a system has free cores to execute Perf tool process during profiling the default system scheduling layout induces the lowest overhead. The patch set has been validated on BT benchmark from NAS Parallel Benchmarks [2] running on dual socket, 44 cores, 88 hw threads Broadwell system with kernels v4.4-21-generic (Ubuntu 16.04) and v4.20.0-rc5 (tip perf/core). OVERHEAD: BENCH REPORT BASED ELAPSED TIME BASED v4.20.0-rc5 (tip perf/core): (current) SERIAL-SYS / BASE : 1.27x (14.37/11.31), 1.29x (15.19/11.69) SERIAL-NODE / BASE : 1.15x (13.04/11.31), 1.17x (13.79/11.69) SERIAL-CPU / BASE : 1.00x (11.32/11.31), 1.01x (11.89/11.69) AIO1-SYS/ BASE : 1.29x (14.58/11.31), 1.29x (15.26/11.69) AIO1-NODE / BASE : 1.08x (12.23/11.31), 1,11x (13.01/11.69) AIO1-CPU/ BASE : 1.07x (12.14/11.31), 1.08x (12.83/11.69) v4.4.0-21-generic (Ubuntu 16.04 LTS): (current) SERIAL-SYS / BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32) SERIAL-NODE / BASE : 1.19x (13.02/10.87), 1.23x (14.03/11.32) SERIAL-CPU / BASE : 1.03x (11.21/10.87), 1.07x (12.18/11.32) AIO1-SYS/ BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32) AIO1-NODE / BASE : 1.10x (12.04/10.87), 1.15x (13.03/11.32) AIO1-CPU/ BASE : 1.12x (12.20/10.87), 1.15x (13.09/11.32) The patch set is generated for acme perf/core repository. --- Alexey Budankov (4): perf record: allocate affinity masks perf record: bind the AIO user space buffers to nodes perf record: apply affinity masks when reading mmap buffers perf record: implement --affinity=node|cpu option tools/perf/Documentation/perf-record.txt | 5 ++ tools/perf/builtin-record.c | 40 ++- tools/perf/perf.h| 8 +++ tools/perf/util/evlist.c | 10 ++-- tools/perf/util/evlist.h | 2 +- tools/perf/util/mmap.c | 63 +++- tools/perf/util/mmap.h | 4 +- 7 files changed, 124 insertions(+), 8 deletions(-) --- Changes in v2: - made debug affinity mode message user friendly - converted affinity mode defines to enum values - implemented perf_mmap__aio_alloc, perf_mmap__aio_free, perf_mmap__aio_bind and put HAVE_LIBNUMA_SUPPORT #ifdefs in there - separated AIO buffers binding to patch 2/4 --- [1] https://en.wikipedia.org/wiki/Non-uniform_memory_access [2] https://www.nas.nasa.gov/publications/npb.html [3] http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html [4] http://man7.org/linux/man-pages/man2/mbind.2.html --- ENVIRONMENT AND MEASUREMENTS: MACHINE: broadwell, dual socket, 44 core, 88 threads /proc/cpuinfo processor : 87 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz stepping: 1 microcode : 0xb19 cpu MHz : 1200.117 cache size : 56320 KB physical id : 1 siblings: 44 core id : 28 cpu cores : 22 apicid : 121 initial apicid : 121 fpu : yes fpu_exception : yes cpuid level : 20 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm
Re: [PATCH v3 6/9] drm/komeda: Add komeda_framebuffer
On Fri, Dec 21, 2018 at 10:00:17AM +, james qian wang (Arm Technology
China) wrote:
> komeda_framebuffer is for extending drm_framebuffer to add komeda own
> attributes and komeda specific fb handling.
>
> Changes in v3:
> - Fixed style problem found by checkpatch.pl --strict.
>
> Signed-off-by: James (Qian) Wang
> ---
> drivers/gpu/drm/arm/display/komeda/Makefile | 3 +-
> .../arm/display/komeda/komeda_framebuffer.c | 165 ++
> .../arm/display/komeda/komeda_framebuffer.h | 31
> 3 files changed, 198 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.h
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
> b/drivers/gpu/drm/arm/display/komeda/Makefile
> index 394fc2aa434a..25beae900ed2 100644
> --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> @@ -8,7 +8,8 @@ komeda-y := \
> komeda_drv.o \
> komeda_dev.o \
> komeda_format_caps.o \
> - komeda_pipeline.o
> + komeda_pipeline.o \
> + komeda_framebuffer.o
>
> komeda-y += \
> d71/d71_dev.o
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> new file mode 100644
> index ..4ddd5314ca23
> --- /dev/null
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> @@ -0,0 +1,165 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> + * Author: James.Qian.Wang
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include "komeda_framebuffer.h"
> +#include "komeda_dev.h"
> +
> +static void komeda_fb_destroy(struct drm_framebuffer *fb)
> +{
> + struct komeda_fb *kfb = to_kfb(fb);
> + u32 i;
> +
> + for (i = 0; i < fb->format->num_planes; i++)
> + drm_gem_object_put_unlocked(fb->obj[i]);
> +
> + drm_framebuffer_cleanup(fb);
> + kfree(kfb);
> +}
> +
> +static int komeda_fb_create_handle(struct drm_framebuffer *fb,
> +struct drm_file *file, u32 *handle)
> +{
> + return drm_gem_handle_create(file, fb->obj[0], handle);
> +}
> +
> +static const struct drm_framebuffer_funcs komeda_fb_funcs = {
> + .destroy= komeda_fb_destroy,
> + .create_handle = komeda_fb_create_handle,
> +};
> +
> +static int
> +komeda_fb_none_afbc_size_check(struct komeda_dev *mdev, struct komeda_fb
> *kfb,
> +struct drm_file *file,
> +const struct drm_mode_fb_cmd2 *mode_cmd)
Not sure what _none stands for here, but otherwise:
Acked-by: Liviu Dudau
Best regards,
Liviu
> +{
> + struct drm_framebuffer *fb = >base;
> + struct drm_gem_object *obj;
> + u32 min_size = 0;
> + u32 i;
> +
> + for (i = 0; i < fb->format->num_planes; i++) {
> + obj = drm_gem_object_lookup(file, mode_cmd->handles[i]);
> + if (!obj) {
> + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> + fb->obj[i] = NULL;
> +
> + return -ENOENT;
> + }
> +
> + kfb->aligned_w = fb->width / (i ? fb->format->hsub : 1);
> + kfb->aligned_h = fb->height / (i ? fb->format->vsub : 1);
> +
> + if (fb->pitches[i] % mdev->chip.bus_width) {
> + DRM_DEBUG_KMS("Pitch[%d]: 0x%x doesn't align to 0x%x\n",
> + i, fb->pitches[i], mdev->chip.bus_width);
> + drm_gem_object_put_unlocked(obj);
> + fb->obj[i] = NULL;
> +
> + return -EINVAL;
> + }
> +
> + min_size = ((kfb->aligned_h / kfb->format_caps->tile_size - 1)
> + * fb->pitches[i])
> + + (kfb->aligned_w * fb->format->cpp[i]
> +* kfb->format_caps->tile_size)
> + + fb->offsets[i];
> +
> + if (obj->size < min_size) {
> + DRM_DEBUG_KMS("Fail to check none afbc fb size.\n");
> + drm_gem_object_put_unlocked(obj);
> + fb->obj[i] = NULL;
> +
> + return -EINVAL;
> + }
> +
> + fb->obj[i] = obj;
> + }
> +
> + if (fb->format->num_planes == 3) {
> + if (fb->pitches[1] != fb->pitches[2]) {
> + DRM_DEBUG_KMS("The pitch[1] and [2] are not same\n");
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +struct drm_framebuffer *
> +komeda_fb_create(struct drm_device *dev, struct drm_file *file,
> + const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + struct komeda_dev *mdev = dev->dev_private;
> + struct komeda_fb *kfb;
> + int ret = 0, i;
> +
> +
Re: [PATCH v2] vfat: don't read garbage after last dirent
Matteo Croce writes: > The FAT32 File System Specification[1] states that: > > If DIR_Name[0] == 0x00, then the directory entry is free, and there > are no allocated directory entries after this one. > > The special 0 value, indicates to FAT file system driver code that > the rest of the entries in this directory do not need to be examined > because they are all free. > > This is not enforced by Linux, and is possible to read garbage if not > all dirents after the last one are filled with zeroes. > > [1] > http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc > > Reported-by: Timothy Redaelli > Signed-off-by: Matteo Croce We have to handle all paths that is using fat_get_entry(), to make consistent behavior. With quick check, there are still several issues remaining. Please check more. For example, looks like fat_parse_long()/fat_search_long() path is missing, and fat_get_dotdot_entry(), fat_subdirs() too. (while adding new entry, if we found zeroed entry, we would be better to warn about fsck.) Thanks. -- OGAWA Hirofumi
Re: [PATCH] firmware/memmap:Modify memblock_alloc to memblock_alloc_nopanic
On Mon, Dec 24, 2018 at 04:41:22PM +0800, huang.zijiang wrote:
> From: "huang.zijiang"
>
> memblock_alloc never returns NULL because panic never returns
>
> Signed-off-by: huang.zijiang
Acked-by: Mike Rapoport
> ---
> drivers/firmware/memmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
> index d168c87..ec4fd25 100644
> --- a/drivers/firmware/memmap.c
> +++ b/drivers/firmware/memmap.c
> @@ -333,7 +333,7 @@ int __init firmware_map_add_early(u64 start, u64 end,
> const char *type)
> {
> struct firmware_map_entry *entry;
>
> - entry = memblock_alloc(sizeof(struct firmware_map_entry),
> + entry = memblock_alloc_nopanic(sizeof(struct firmware_map_entry),
> SMP_CACHE_BYTES);
> if (WARN_ON(!entry))
> return -ENOMEM;
> --
> 1.8.3.1
>
--
Sincerely yours,
Mike.
