* Re: Aw: Re: barebox - rk3568
From: Ahmad Fatoum @ 2022-01-05 16:08 UTC (permalink / raw)
To: Frank Wunderlich; +Cc: barebox
In-Reply-To: <trinity-cf421ba4-410b-4e0e-bb2f-60fef962bc97-1641397322119@3c-app-gmx-bs58>
On 05.01.22 16:42, Frank Wunderlich wrote:
>> Gesendet: Mittwoch, 05. Januar 2022 um 13:08 Uhr
>> Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de>
>> An: "Frank Wunderlich" <frank-w@public-files.de>, barebox@lists.infradead.org
>> Betreff: Re: barebox - rk3568
>
>>> https://www.barebox.org/doc/latest/boards/rockchip.html#rockchip-rk3568
>>>
>>> says it starts from sector 32, my first block for uboot (idblock.bin=spl+raminit) starts at 64, full uboot in partition at 8M.
>>
>> You probably figured it out by now, but the discrepancy is likely due to differing
>> block sizes. barebox documentation has `dd bs=1024`, while the default is 512.
>> boot firmware is a single chunk with barebox, so no separate second stage bootloader
>> partition.
>
> thanks, this indeed explain the different offset, which is same after resolving the double blocksize
>
>>> As it differs a bit from evb can i add new dts like in uboot?
>>
>> You can check out the commit adding the EVB or the Pine64 Quartz64:
>> 8d14f8e898b4 ("arm: rockchip: add support for the quartz64 board")
>>
>> Feel free to send patches for your board along the same lines. :)
>
> currently evb is working well, so i try to add bootscripts and maybe an menu (if i found out how) :)
It's not EVB anymore though, if you replace the device tree and skip the board code. ;)
>
> regards Frank
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* MES:
From: Mustafa Ayvaz @ 2022-01-05 15:50 UTC (permalink / raw)
To: linux-pm
Hello linux-pm,
I was only wondering if you got my previous email? I have been
trying to reach you on your email linux-pm@vger.kernel.org ,
kindly get back to me swiftly, it is very important.
Thanks
Mustafa Ayvaz
mustafa@ayvazburosu.com
^ permalink raw reply
* Re: [PATCH 2/3] selftests/kexec: Enable secureboot tests for PowerPC
From: Nayna @ 2022-01-05 16:09 UTC (permalink / raw)
To: Nageswara R Sastry, zohar, linux-kselftest, linux-integrity, mpe,
shuah
Cc: nayna, dja, gcwilson
In-Reply-To: <20211124070802.1765-2-rnsastry@linux.ibm.com>
On 11/24/21 02:08, Nageswara R Sastry wrote:
> Existing test cases determine secureboot state using efi variable, which is
> available only on x86 architecture.
> Add support for determining secureboot state using device tree property on
> PowerPC architecture.
Please replace 'PowerPC' with 'PowerNV'.
Rest looks good.
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: Nayna Jain <nayna@linux.ibm.com>
Thanks & Regards,
- Nayna
^ permalink raw reply
* MES:
From: Mustafa Ayvaz @ 2022-01-05 15:49 UTC (permalink / raw)
To: linux-ide
Hello linux-ide,
I was only wondering if you got my previous email? I have been
trying to reach you on your email linux-ide@vger.kernel.org ,
kindly get back to me swiftly, it is very important.
Thanks
Mustafa Ayvaz
mustafa@ayvazburosu.com
^ permalink raw reply
* Re: [PATCH net-next v6] rtnetlink: Support fine-grained netdevice bulk deletion
From: David Ahern @ 2022-01-05 16:09 UTC (permalink / raw)
To: Lahav Schlesinger, Eric Dumazet
Cc: netdev, kuba, idosch, nicolas.dichtel, nikolay
In-Reply-To: <df31afed-13a2-a02b-a5f8-4b76c57631d3@gmail.com>
On 1/4/22 5:18 PM, David Ahern wrote:
> On 1/4/22 1:40 PM, Lahav Schlesinger wrote:
>> I tried using dev->unreg_list but it doesn't work e.g. for veth pairs
>> where ->dellink() of a veth automatically adds the peer. Therefore if
>> @ifindices contains both peers then the first ->dellink() will remove
>> the next device from @list_kill. This caused a page fault when
>> @list_kill was further iterated on.
>
> make sure you add a selftest for the bulk delete and cover cases with
> veth, vlan, vrf, dummy, bridge, ...
>
BTW, delete of a netdev clears out neighbor entries, network addresses,
routes, hardware updates, etc. with lots of notifications to userspace.
Bulk delete of 1000s of netdevs is going to end up holding the rtnl for
a "long" time. It would be good for the selftests to include a cases
with lots of neighbor entries, routes, addresses.
^ permalink raw reply
* MES:
From: Mustafa Ayvaz @ 2022-01-05 15:49 UTC (permalink / raw)
To: linux-media
Hello linux-media,
I was only wondering if you got my previous email? I have been
trying to reach you on your email linux-media@vger.kernel.org ,
kindly get back to me swiftly, it is very important.
Thanks
Mustafa Ayvaz
mustafa@ayvazburosu.com
^ permalink raw reply
* Re: [PATCH] RDMA: null pointer in __ib_umem_release causes kernel panic
From: Jason Gunthorpe @ 2022-01-05 16:09 UTC (permalink / raw)
To: Trond Myklebust
Cc: trondmy@kernel.org, linux-nfs@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <3b74b8f4481ec27debad500e53facc56f9b388cd.camel@hammerspace.com>
On Wed, Jan 05, 2022 at 03:02:34PM +0000, Trond Myklebust wrote:
> On Wed, 2022-01-05 at 10:37 -0400, Jason Gunthorpe wrote:
> > On Wed, Jan 05, 2022 at 09:18:41AM -0500, trondmy@kernel.org wrote:
> > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > >
> > > When doing RPC/RDMA, we're seeing a kernel panic when
> > > __ib_umem_release()
> > > iterates over the scatter gather list and hits NULL pages.
> > >
> > > It turns out that commit 79fbd3e1241c ended up changing the
> > > iteration
> > > from being over only the mapped entries to being over the original
> > > list
> > > size.
> >
> > You mean this?
> >
> > - for_each_sg(umem->sg_head.sgl, sg, umem->sg_nents, i)
> > + for_each_sgtable_sg(&umem->sgt_append.sgt, sg, i)
> >
> > I don't see what changed there? The invarient should be that
> >
> > umem->sg_nents == sgt->orig_nents
> >
> > > @@ -55,7 +55,7 @@ static void __ib_umem_release(struct ib_device
> > > *dev, struct ib_umem *umem, int d
> > > ib_dma_unmap_sgtable_attrs(dev, &umem-
> > > >sgt_append.sgt,
> > > DMA_BIDIRECTIONAL, 0);
> > >
> > > - for_each_sgtable_sg(&umem->sgt_append.sgt, sg, i)
> > > + for_each_sgtable_dma_sg(&umem->sgt_append.sgt, sg, i)
> > > unpin_user_page_range_dirty_lock(sg_page(sg),
> >
> > Calling sg_page() from under a dma_sg iterator is unconditionally
> > wrong..
> >
> > More likely your case is something has gone wrong when the sgtable
> > was
> > created and it has the wrong value in orig_nents..
>
> Can you define "wrong value" in this case? Chuck's RPC/RDMA code
> appears to call ib_alloc_mr() with an 'expected maximum number of
> entries' (depth) in net/sunrpc/xprtrdma/frwr_ops.c:frwr_mr_init().
>
> It then fills that table with a set of n <= depth pages in
> net/sunrpc/xprtrdma/frwr_ops.c:frwr_map() and calls ib_dma_map_sg() to
> map them, and then adjusts the sgtable with a call to ib_map_mr_sg().
I'm confused, RPC/RDMA should never touch a umem at all.
Is this really the other bug where user and kernel MR are getting
confused?
Jason
^ permalink raw reply
* MES:
From: Mustafa Ayvaz @ 2022-01-05 15:49 UTC (permalink / raw)
To: linux-scsi
Hello linux-scsi,
I was only wondering if you got my previous email? I have been
trying to reach you on your email linux-scsi@vger.kernel.org ,
kindly get back to me swiftly, it is very important.
Thanks
Mustafa Ayvaz
mustafa@ayvazburosu.com
^ permalink raw reply
* Re: barebox extending boot-scripts
From: Ahmad Fatoum @ 2022-01-05 16:07 UTC (permalink / raw)
To: Frank Wunderlich, barebox
In-Reply-To: <trinity-236a89db-cfb0-4d29-bf25-44dc71d5d143-1641396043420@3c-app-gmx-bs58>
Hi,
On 05.01.22 16:20, Frank Wunderlich wrote:
> Hi,
>
> i'm making my first steps and try to add more boot-scripts (to land in /env/boot)
>
> i added a scipt in
>
> arch/arm/boards/rockchip-rk3568-evb/defaultenv/mmc-linux
This should be defaultenv/boot/mmc-linux instead.
> and set
>
> DEFAULT_ENVIRONMENT_PATH [=arch/arm/boards/rockchip-rk3568-evb/defaultenv]
>
> but if i boot the board /env/boot only contains the 2 default scripts
>
> barebox@Rockchip RK3568 EVB:/ ls /env/boot/
> bnet net
Try ls -R /env, you should see mmc-linux at top-level with your
current setup.
> so maybe the dir/config-option i used is for defining variables only right?
Top level is only meant for directories. There are directories for the different
stuff, e.g. variables go into /env/nv/
> should this point to an directory or a file?
The config option is meant for use with external build systems, e.g. buildroot
or PTXdist. For boards in-tree, you can add bbenv-y in the Makefile and call
// assuming directory is called defaultenv-myboard
defaultenv_append_directory(defaultenv_myboard);
in the board code, see e.g. arch/arm/boards/embest-marsboard for an example.
The reason for avoiding the config option for in-tree boards is that a single barebox
configuration can build multiple boards in one go:
extreme case: imx_v7_defconfig, which builds marsboard also builds more than 100 other images.
The config option is global, but by explicitly calling defaultenv_append_directory,
you can have board-specific environments.
> i see this file which looks like the source of it
>
> ./defaultenv/defaultenv-2-base/boot/net
>
> I've put them there and they appear, but this is not board specific
Ye, you can use this for debugging, but stuff upstreamed there must be generally
applicable.
> so if i later want to upstream one this is maybe not the right place.
Boot scripts for publicly available evaluation kits are often not good candidates
for upstreaming, because everybody using the EVKs has different thoughts on how to
boot. The best way would be to use bootloader spec. It's one or more files you
place at a known location that describe where your kernel and device tree are and
what command line arguments to use and barebox can then automatically generate
boot entries from all available bootloader spec files.
See https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf for an example
of how to set this up. This is what I'd recommend instead of writing your own
scripts.
> ./defaultenv/defaultenv-2-menu/menu/10-boot-all/net
>
> seems to be a menu entry, but have not yet figured out how i can define one to add my scripts too
>
> have not found anything for it in the documentation yet
The default boot menu is populated with the boot entries extracted from
the contents of $global.boot.default.
boot -m will display that menu. It will also include all bootloader spec files.
If that suffices, you won't need to create your own menu. If you want though,
check the help text of the menutree command.
To boot into the boot menu, set nv autoboot=menu. "Detect bootsources" will
list boot sources known to the barebox boot command.
See magicvar for a listing of all magic variables, or refer to the documentation.
> btw. is there a way to use ls with wildcard without printing the path?
>
> ls /mnt/sd.1/extlinux/
> Image_5.16 Image_5.16-next.gz Image_5.16.gz
>
> ls /mnt/sd.1/extlinux/Image*
> /mnt/sd.1/extlinux/Image_5.16
> /mnt/sd.1/extlinux/Image_5.16-next.gz
> /mnt/sd.1/extlinux/Image_5.16.gz
>
> i want to list only files matching Image*, but without path....number of columns does not matter
Yes, cd /mnt/sd.1/extlinux
Cheers,
Ahmad
>
> regards Frank
>
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH RFC] can: isotp: convert struct tpcon::{idx,len} to unsigned int
From: Oliver Hartkopp @ 2022-01-05 16:08 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can; +Cc: syzbot+4c63f36709a642f801c5
In-Reply-To: <20220105132429.1170627-1-mkl@pengutronix.de>
On 05.01.22 14:24, Marc Kleine-Budde wrote:
> In isotp_rcv_ff() 32 bit of data received over the network is assigned
> to struct tpcon::len. Later in that function the length is checked for
> the maximal supported length against MAX_MSG_LENGTH.
>
> As struct tpcon::len is an "int" this check does not work, if the
> provided length overflows the "int".
>
> Later on struct tpcon::idx is compared against struct tpcon::len.
>
> To fix this problem this patch converts both struct tpcon::{idx,len}
> to unsigned int.
>
> Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
> \# Cc: stable@vger.kernel.org
> Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks Marc!
> Reported-by: syzbot+4c63f36709a642f801c5@syzkaller.appspotmail.com
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ---
> net/can/isotp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/can/isotp.c b/net/can/isotp.c
> index df6968b28bf4..02cbcb2ecf0d 100644
> --- a/net/can/isotp.c
> +++ b/net/can/isotp.c
> @@ -119,8 +119,8 @@ enum {
> };
>
> struct tpcon {
> - int idx;
> - int len;
> + unsigned int idx;
> + unsigned int len;
> u32 state;
> u8 bs;
> u8 sn;
>
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 1/4] drm/i915: don't call free_mmap_offset when purging
From: Thomas Hellström @ 2022-01-05 16:06 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
In-Reply-To: <0bdf49e1-f446-c3de-4308-a774bc3e82d5@intel.com>
On Wed, 2022-01-05 at 16:03 +0000, Matthew Auld wrote:
> On 05/01/2022 15:46, Thomas Hellström wrote:
> > On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
> > > The TTM backend is in theory the only user here(also purge should
> > > only
> > > be called once we have dropped the pages), where it is setup at
> > > object
> > > creation and is only removed once the object is destroyed. Also
> > > resetting the node here might be iffy since the ttm fault handler
> > > uses the stored fake offset to determine the page offset within
> > > the
> > > pages
> > > array.
> > >
> > > This also blows up in the dontneed-before-mmap test, since the
> > > expectation is that the vma_node will live on, until the object
> > > is
> > > destroyed:
> > >
> > > <2> [749.062902] kernel BUG at
> > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c:943!
> > > <4> [749.062923] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
> > > <4> [749.062928] CPU: 0 PID: 1643 Comm: gem_madvise Tainted:
> > > G U
> > > W 5.16.0-rc8-CI-CI_DRM_11046+ #1
> > > <4> [749.062933] Hardware name: Gigabyte Technology Co., Ltd. GB-
> > > Z390
> > > Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019
> > > <4> [749.062937] RIP: 0010:i915_ttm_mmap_offset.cold.35+0x5b/0x5d
> > > [i915]
> > > <4> [749.063044] Code: 00 48 c7 c2 a0 23 4e a0 48 c7 c7 26 df 4a
> > > a0
> > > e8 95 1d d0 e0 bf 01 00 00 00 e8 8b ec cf e0 31 f6 bf 09 00 00 00
> > > e8
> > > 5f 30 c0 e0 <0f> 0b 48 c7 c1 24 4b 56 a0 ba 5b 03 00 00 48 c7 c6
> > > c0
> > > 23 4e a0 48
> > > <4> [749.063052] RSP: 0018:ffffc90002ab7d38 EFLAGS: 00010246
> > > <4> [749.063056] RAX: 0000000000000240 RBX: ffff88811f2e61c0 RCX:
> > > 0000000000000006
> > > <4> [749.063060] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> > > 0000000000000009
> > > <4> [749.063063] RBP: ffffc90002ab7e58 R08: 0000000000000001 R09:
> > > 0000000000000001
> > > <4> [749.063067] R10: 000000000123d0f8 R11: ffffc90002ab7b20 R12:
> > > ffff888112a1a000
> > > <4> [749.063071] R13: 0000000000000004 R14: ffff88811f2e61c0 R15:
> > > ffff888112a1a000
> > > <4> [749.063074] FS: 00007f6e5fcad500(0000)
> > > GS:ffff8884ad600000(0000) knlGS:0000000000000000
> > > <4> [749.063078] CS: 0010 DS: 0000 ES: 0000 CR0:
> > > 0000000080050033
> > > <4> [749.063081] CR2: 00007efd264e39f0 CR3: 0000000115fd6005 CR4:
> > > 00000000003706f0
> > > <4> [749.063085] Call Trace:
> > > <4> [749.063087] <TASK>
> > > <4> [749.063089] __assign_mmap_offset+0x41/0x300 [i915]
> > > <4> [749.063171] __assign_mmap_offset_handle+0x159/0x270 [i915]
> > > <4> [749.063248] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
> > > <4> [749.063325] drm_ioctl_kernel+0xae/0x140
> > > <4> [749.063330] drm_ioctl+0x201/0x3d0
> > > <4> [749.063333] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
> > > <4> [749.063409] ? do_user_addr_fault+0x200/0x670
> > > <4> [749.063415] __x64_sys_ioctl+0x6d/0xa0
> > > <4> [749.063419] do_syscall_64+0x3a/0xb0
> > > <4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae
> > > <4> [749.063428] RIP: 0033:0x7f6e5f100317
> > >
> > > Testcase: igt@gem_madvise@dontneed-before-mmap
> > > Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm
> > > bo's.")
> > > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_pages.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > > index 89b70f5cde7a..9f429ed6e78a 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > > @@ -161,7 +161,6 @@ int i915_gem_object_pin_pages_unlocked(struct
> > > drm_i915_gem_object *obj)
> > > /* Immediately discard the backing storage */
> > > int i915_gem_object_truncate(struct drm_i915_gem_object *obj)
> > > {
> > > - drm_gem_free_mmap_offset(&obj->base);
> >
> > What happens if a non-ttm shmem system object gets truncated from
> > the
> > shrinker and then tries to use the above mmap offset?
>
> AFAIK nothing on integrated is really using this. The mmap_offset
> ioctl
> stuff is managing multiple vma nodes itself, per object(one for each
> cache type/mapping or something), and so doesn't use this. And the
> shmem
> mmap ioctl doesn't use the any fake offset stuff, AFAIK.
OK, then
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>
> >
> > /Thomas
> >
> >
> >
> > > if (obj->ops->truncate)
> > > return obj->ops->truncate(obj);
> > >
> >
> >
^ permalink raw reply
* Re: [PATCH 1/4] drm/i915: don't call free_mmap_offset when purging
From: Thomas Hellström @ 2022-01-05 16:06 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
In-Reply-To: <0bdf49e1-f446-c3de-4308-a774bc3e82d5@intel.com>
On Wed, 2022-01-05 at 16:03 +0000, Matthew Auld wrote:
> On 05/01/2022 15:46, Thomas Hellström wrote:
> > On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
> > > The TTM backend is in theory the only user here(also purge should
> > > only
> > > be called once we have dropped the pages), where it is setup at
> > > object
> > > creation and is only removed once the object is destroyed. Also
> > > resetting the node here might be iffy since the ttm fault handler
> > > uses the stored fake offset to determine the page offset within
> > > the
> > > pages
> > > array.
> > >
> > > This also blows up in the dontneed-before-mmap test, since the
> > > expectation is that the vma_node will live on, until the object
> > > is
> > > destroyed:
> > >
> > > <2> [749.062902] kernel BUG at
> > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c:943!
> > > <4> [749.062923] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
> > > <4> [749.062928] CPU: 0 PID: 1643 Comm: gem_madvise Tainted:
> > > G U
> > > W 5.16.0-rc8-CI-CI_DRM_11046+ #1
> > > <4> [749.062933] Hardware name: Gigabyte Technology Co., Ltd. GB-
> > > Z390
> > > Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019
> > > <4> [749.062937] RIP: 0010:i915_ttm_mmap_offset.cold.35+0x5b/0x5d
> > > [i915]
> > > <4> [749.063044] Code: 00 48 c7 c2 a0 23 4e a0 48 c7 c7 26 df 4a
> > > a0
> > > e8 95 1d d0 e0 bf 01 00 00 00 e8 8b ec cf e0 31 f6 bf 09 00 00 00
> > > e8
> > > 5f 30 c0 e0 <0f> 0b 48 c7 c1 24 4b 56 a0 ba 5b 03 00 00 48 c7 c6
> > > c0
> > > 23 4e a0 48
> > > <4> [749.063052] RSP: 0018:ffffc90002ab7d38 EFLAGS: 00010246
> > > <4> [749.063056] RAX: 0000000000000240 RBX: ffff88811f2e61c0 RCX:
> > > 0000000000000006
> > > <4> [749.063060] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> > > 0000000000000009
> > > <4> [749.063063] RBP: ffffc90002ab7e58 R08: 0000000000000001 R09:
> > > 0000000000000001
> > > <4> [749.063067] R10: 000000000123d0f8 R11: ffffc90002ab7b20 R12:
> > > ffff888112a1a000
> > > <4> [749.063071] R13: 0000000000000004 R14: ffff88811f2e61c0 R15:
> > > ffff888112a1a000
> > > <4> [749.063074] FS: 00007f6e5fcad500(0000)
> > > GS:ffff8884ad600000(0000) knlGS:0000000000000000
> > > <4> [749.063078] CS: 0010 DS: 0000 ES: 0000 CR0:
> > > 0000000080050033
> > > <4> [749.063081] CR2: 00007efd264e39f0 CR3: 0000000115fd6005 CR4:
> > > 00000000003706f0
> > > <4> [749.063085] Call Trace:
> > > <4> [749.063087] <TASK>
> > > <4> [749.063089] __assign_mmap_offset+0x41/0x300 [i915]
> > > <4> [749.063171] __assign_mmap_offset_handle+0x159/0x270 [i915]
> > > <4> [749.063248] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
> > > <4> [749.063325] drm_ioctl_kernel+0xae/0x140
> > > <4> [749.063330] drm_ioctl+0x201/0x3d0
> > > <4> [749.063333] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
> > > <4> [749.063409] ? do_user_addr_fault+0x200/0x670
> > > <4> [749.063415] __x64_sys_ioctl+0x6d/0xa0
> > > <4> [749.063419] do_syscall_64+0x3a/0xb0
> > > <4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae
> > > <4> [749.063428] RIP: 0033:0x7f6e5f100317
> > >
> > > Testcase: igt@gem_madvise@dontneed-before-mmap
> > > Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm
> > > bo's.")
> > > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_pages.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > > index 89b70f5cde7a..9f429ed6e78a 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > > @@ -161,7 +161,6 @@ int i915_gem_object_pin_pages_unlocked(struct
> > > drm_i915_gem_object *obj)
> > > /* Immediately discard the backing storage */
> > > int i915_gem_object_truncate(struct drm_i915_gem_object *obj)
> > > {
> > > - drm_gem_free_mmap_offset(&obj->base);
> >
> > What happens if a non-ttm shmem system object gets truncated from
> > the
> > shrinker and then tries to use the above mmap offset?
>
> AFAIK nothing on integrated is really using this. The mmap_offset
> ioctl
> stuff is managing multiple vma nodes itself, per object(one for each
> cache type/mapping or something), and so doesn't use this. And the
> shmem
> mmap ioctl doesn't use the any fake offset stuff, AFAIK.
OK, then
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>
> >
> > /Thomas
> >
> >
> >
> > > if (obj->ops->truncate)
> > > return obj->ops->truncate(obj);
> > >
> >
> >
^ permalink raw reply
* Re: [RFC Patch v3] binman: add support for creating dummy files for external blobs
From: Simon Glass @ 2022-01-05 16:06 UTC (permalink / raw)
To: Heiko Thiery
Cc: U-Boot Mailing List, Stefano Babic, Fabio Estevam, Michael Walle,
Tom Rini, Wolfgang Denk
In-Reply-To: <20220105125816.197045-1-heiko.thiery@gmail.com>
Hi Heiko,
On Wed, 5 Jan 2022 at 05:58, Heiko Thiery <heiko.thiery@gmail.com> wrote:
>
> While converting to binman for an imx8mq board, it has been found that
> building in the u-boot CI fails. This is because an imx8mq requires an
> external binary (signed_hdmi_imx8m.bin). If this file cannot be found
> mkimage fails.
> To be able to build this board in the u-boot CI a binman option
> (--fake-ext-blobs) is introduced that can be switched on via the u-boot
> makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy files are
> created.
>
> Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
> ---
> v3:
> - add CheckFakedBlobs() and print a list of faked files at the end
> - add unittest
>
> v2:
> - pass allow_fake_blobs to ProcessImage()
> - set AllowAllowFakeBlob() to images/entries
> - create fake blob in Entry_blot.ObtainContents() when file is missing and
> creation is allowed
>
> still missing:
> - unittest
> - option to set BINMAN_FAKE_EXT_BLOBS in Makefile via environment
> variable. With that we could simply set this env variable in the CI
> (gitlab-ci.yml) with adding support to buildman.
>
> Makefile | 1 +
> tools/binman/cmdline.py | 2 ++
> tools/binman/control.py | 26 +++++++++++++++++++-------
> tools/binman/entry.py | 23 +++++++++++++++++++++++
> tools/binman/etype/blob.py | 18 ++++++++++++++++++
> tools/binman/etype/blob_ext.py | 8 ++++++++
> tools/binman/etype/mkimage.py | 20 ++++++++++++++++++++
> tools/binman/etype/section.py | 20 ++++++++++++++++++++
> tools/binman/ftest.py | 13 ++++++++++++-
> tools/binman/test/203_fake_blob.dts | 14 ++++++++++++++
> 10 files changed, 137 insertions(+), 8 deletions(-)
> create mode 100644 tools/binman/test/203_fake_blob.dts
Please check that you keep to 80cols, except where it would split a string.
This is missing a few holes in test coverage. Did you try 'binman test -T' ?
If you are stuck I could fiddle with it a bit.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH] ext4/033: test EXT4_IOC_RESIZE_FS by calling the ioctl directly
From: Zorro Lang @ 2022-01-05 16:06 UTC (permalink / raw)
To: Theodore Ts'o, guan, fstests, Ext4 Developers List,
Eric Whitney
In-Reply-To: <20220105155743.6knpj4zsbmy62uwj@zlang-mailbox>
On Wed, Jan 05, 2022 at 11:57:43PM +0800, Zorro Lang wrote:
> On Mon, Dec 20, 2021 at 03:40:59PM -0500, Theodore Ts'o wrote:
> > E2fsprogs commits 4ea80d031c7e ("resize2fs: adjust new size of the
> > file system to allow a successful resize") and 50088b1996cc
> > ("resize2fs: attempt to keep the # of inodes valid by removing the
> > last bg") will automatically reduce the requested new size of the file
> > system by up to a single block group to avoid overflowing the 32-bit
> > inode count. This interferes with ext4/033's test of kernel commit
> > 4f2f76f75143 ("ext4: Forbid overflowing inode count when # resizing".)
> >
> > Address this by creating a new test program, ext4_resize which calls
> > the EXT4_IOC_RESIZE_FS ioctl directly so we can correctly test the
> > kernel's online resize code.
> >
> > Reported-by: Eric Whitney <enwlinux@gmail.com>
> > Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> > ---
> > .gitignore | 1 +
> > src/Makefile | 2 +-
> > src/ext4_resize.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++
> > tests/ext4/033 | 16 ++++++++++-----
> > 4 files changed, 63 insertions(+), 6 deletions(-)
> > create mode 100644 src/ext4_resize.c
> >
> > diff --git a/.gitignore b/.gitignore
> > index 9e6d2fd5..65b93307 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -77,6 +77,7 @@ tags
> > /src/dirperf
> > /src/dirstress
> > /src/e4compact
> > +/src/ext4_resize
> > /src/fault
> > /src/feature
> > /src/fiemap-tester
> > diff --git a/src/Makefile b/src/Makefile
> > index 25ab061d..1737ed0e 100644
> > --- a/src/Makefile
> > +++ b/src/Makefile
> > @@ -31,7 +31,7 @@ LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
> > dio-invalidate-cache stat_test t_encrypted_d_revalidate \
> > attr_replace_test swapon mkswap t_attr_corruption t_open_tmpfiles \
> > fscrypt-crypt-util bulkstat_null_ocount splice-test chprojid_fail \
> > - detached_mounts_propagation
> > + detached_mounts_propagation ext4_resize
> >
> > EXTRA_EXECS = dmerror fill2attr fill2fs fill2fs_check scaleread.sh \
> > btrfs_crc32c_forged_name.py
> > diff --git a/src/ext4_resize.c b/src/ext4_resize.c
> > new file mode 100644
> > index 00000000..1ac51e6f
> > --- /dev/null
> > +++ b/src/ext4_resize.c
> > @@ -0,0 +1,50 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/*
> > + * Test program which uses the raw ext4 resize_fs ioctl directly.
> > + */
> > +
> > +#include <stdio.h>
> > +#include <fcntl.h>
> > +#include <errno.h>
> > +#include <unistd.h>
> > +#include <stdint.h>
> > +#include <stdlib.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/mount.h>
> > +
> > +typedef unsigned long long __u64;
> > +
> > +#ifndef EXT4_IOC_RESIZE_FS
> > +#define EXT4_IOC_RESIZE_FS _IOW('f', 16, __u64)
> > +#endif
>
> This patch looks good to me, I just want to ask if we'd better to try to include
> ext2fs/ext2fs.h at here? And of course, check it in configure.ac.
> The EXT4_IOC_RESIZE_FS looks like defined in ext2fs/ext2_fs.h which comes from
> e2fsprogs-devel package. I can't find this definition from kernel-hearders package.
> As you're the expert of this part, please correct me if it's wrong :)
Oh, I just noticed that this patch has been merged. I have no idea why this email become
*unread* status in my mutt, cause I thought it's a new patch. Please ignore this review.
>
> Thanks,
> Zorro
>
> > +
> > +int main(int argc, char **argv)
> > +{
> > + __u64 new_size;
> > + int error, fd;
> > + char *tmp = NULL;
> > +
> > + if (argc != 3) {
> > + fputs("insufficient arguments\n", stderr);
> > + return 1;
> > + }
> > + fd = open(argv[1], O_RDONLY);
> > + if (!fd) {
> > + perror(argv[1]);
> > + return 1;
> > + }
> > +
> > + new_size = strtoull(argv[2], &tmp, 10);
> > + if ((errno) || (*tmp != '\0')) {
> > + fprintf(stderr, "%s: invalid new size\n", argv[0]);
> > + return 1;
> > + }
> > +
> > + error = ioctl(fd, EXT4_IOC_RESIZE_FS, &new_size);
> > + if (error < 0) {
> > + perror("EXT4_IOC_RESIZE_FS");
> > + return 1;
> > + }
> > + return 0;
> > +}
> > diff --git a/tests/ext4/033 b/tests/ext4/033
> > index 1bc14c03..22041a17 100755
> > --- a/tests/ext4/033
> > +++ b/tests/ext4/033
> > @@ -5,7 +5,8 @@
> > # FS QA Test 033
> > #
> > # Test s_inodes_count overflow for huge filesystems. This bug was fixed
> > -# by commit "ext4: Forbid overflowing inode count when resizing".
> > +# by commit 4f2f76f75143 ("ext4: Forbid overflowing inode count when
> > +# resizing".)
> > #
> > . ./common/preamble
> > _begin_fstest auto ioctl resize
> > @@ -28,7 +29,9 @@ _supported_fs ext4
> > _require_scratch_nocheck
> > _require_dmhugedisk
> > _require_dumpe2fs
> > -_require_command "$RESIZE2FS_PROG" resize2fs
> > +_require_test_program ext4_resize
> > +
> > +EXT4_RESIZE=$here/src/ext4_resize
> >
> > # Figure out whether device is large enough
> > devsize=$(blockdev --getsize64 $SCRATCH_DEV)
> > @@ -68,7 +71,8 @@ $DUMPE2FS_PROG -h $DMHUGEDISK_DEV >> $seqres.full 2>&1
> >
> > # This should fail, s_inodes_count would just overflow!
> > echo "Resizing to inode limit + 1..."
> > -$RESIZE2FS_PROG $DMHUGEDISK_DEV $((limit_groups*group_blocks)) >> $seqres.full 2>&1
> > +echo $EXT4_RESIZE $SCRATCH_MNT $((limit_groups*group_blocks)) >> $seqres.full 2>&1
> > +$EXT4_RESIZE $SCRATCH_MNT $((limit_groups*group_blocks)) >> $seqres.full 2>&1
> > if [ $? -eq 0 ]; then
> > echo "Resizing succeeded but it should fail!"
> > exit
> > @@ -76,7 +80,8 @@ fi
> >
> > # This should succeed, we are maxing out inodes
> > echo "Resizing to max group count..."
> > -$RESIZE2FS_PROG $DMHUGEDISK_DEV $(((limit_groups-1)*group_blocks)) >> $seqres.full 2>&1
> > +echo $EXT4_RESIZE $SCRATCH_MNT $(((limit_groups-1)*group_blocks)) >> $seqres.full 2>&1
> > +$EXT4_RESIZE $SCRATCH_MNT $(((limit_groups-1)*group_blocks)) >> $seqres.full 2>&1
> > if [ $? -ne 0 ]; then
> > echo "Resizing failed!"
> > exit
> > @@ -87,7 +92,8 @@ $DUMPE2FS_PROG -h $DMHUGEDISK_DEV >> $seqres.full 2>&1
> >
> > # This should fail, s_inodes_count would overflow by quite a bit!
> > echo "Resizing to device size..."
> > -$RESIZE2FS_PROG $DMHUGEDISK_DEV >> $seqres.full 2>&1
> > +echo $EXT4_RESIZE $SCRATCH_MNT $(((limit_groups + 16)*group_blocks)) >> $seqres.full 2>&1
> > +$EXT4_RESIZE $SCRATCH_MNT $(((limit_groups + 16)*group_blocks)) >> $seqres.full 2>&1
> > if [ $? -eq 0 ]; then
> > echo "Resizing succeeded but it should fail!"
> > exit
> > --
> > 2.31.0
> >
^ permalink raw reply
* Re: [PATCH] Revert "net: usb: r8152: Add MAC passthrough support for more Lenovo Docks"
From: Aaron Ma @ 2022-01-05 16:05 UTC (permalink / raw)
To: Oliver Neukum, kuba, henning.schild, linux-usb, netdev,
linux-kernel
Cc: davem, hayeswang, tiwai
In-Reply-To: <394d86b6-bb22-9b44-fa1e-8fdc6366d55e@suse.com>
On 1/6/22 00:01, Oliver Neukum wrote:
>
> On 05.01.22 16:51, Aaron Ma wrote:
>> This reverts commit f77b83b5bbab53d2be339184838b19ed2c62c0a5.
>>
>> This change breaks multiple usb to ethernet dongles attached on Lenovo
>> USB hub.
>
> Hi,
>
> now we should maybe discuss a sensible way to identify device
> that should use passthrough. Are your reasons to not have a list
> of devices maintainability or is it impossible?
>
The USB to ethernet ID is 0bda:8153. It's is original Realtek 8153 ID.
It's impossible.
And ocp data are 0.
No way to identify it's from dock.
Aaron
> Regards
> Oliver
>
^ permalink raw reply
* [PATCH v3 3/3] x86: Add test for arch_prctl(ARCH_VSYSCALL_CONTROL)
From: Florian Weimer @ 2022-01-05 16:03 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-arch, Linux API, linux-x86_64, kernel-hardening, linux-mm,
the arch/x86 maintainers, musl, libc-alpha, linux-kernel,
Dave Hansen, Kees Cook, Andrei Vagin
In-Reply-To: <54ae0e1f8928160c1c4120263ea21c8133aa3ec4.1641398395.git.fweimer@redhat.com>
Signed-off-by: Florian Weimer <fweimer@redhat.com>
---
v3: Patch split out.
tools/arch/x86/include/uapi/asm/prctl.h | 2 +
tools/testing/selftests/x86/Makefile | 7 +-
.../testing/selftests/x86/vsyscall_control.c | 891 ++++++++++++++++++
3 files changed, 899 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/x86/vsyscall_control.c
diff --git a/tools/arch/x86/include/uapi/asm/prctl.h b/tools/arch/x86/include/uapi/asm/prctl.h
index 754a07856817..aad0bcfbf49f 100644
--- a/tools/arch/x86/include/uapi/asm/prctl.h
+++ b/tools/arch/x86/include/uapi/asm/prctl.h
@@ -18,4 +18,6 @@
#define ARCH_MAP_VDSO_32 0x2002
#define ARCH_MAP_VDSO_64 0x2003
+#define ARCH_VSYSCALL_CONTROL 0x5001
+
#endif /* _ASM_X86_PRCTL_H */
diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile
index 0993d12f2c38..4c751836bfeb 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -18,7 +18,7 @@ TARGETS_C_32BIT_ONLY := entry_from_vm86 test_syscall_vdso unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \
vdso_restorer
TARGETS_C_64BIT_ONLY := fsgsbase sysret_rip syscall_numbering \
- corrupt_xstate_header amx
+ corrupt_xstate_header amx vsyscall_control
# Some selftests require 32bit support enabled also on 64bit systems
TARGETS_C_32BIT_NEEDED := ldt_gdt ptrace_syscall
@@ -107,3 +107,8 @@ $(OUTPUT)/test_syscall_vdso_32: thunks_32.S
# state.
$(OUTPUT)/check_initial_reg_state_32: CFLAGS += -Wl,-ereal_start -static
$(OUTPUT)/check_initial_reg_state_64: CFLAGS += -Wl,-ereal_start -static
+
+# This test does not link against anything (neither libc nor libgcc).
+$(OUTPUT)/vsyscall_control_64: \
+ LIBS := -Wl,-no-pie -static -nostdlib -nostartfiles
+ CFLAGS += -fno-pie -fno-stack-protector -fno-builtin -ffreestanding
diff --git a/tools/testing/selftests/x86/vsyscall_control.c b/tools/testing/selftests/x86/vsyscall_control.c
new file mode 100644
index 000000000000..ee966f936c89
--- /dev/null
+++ b/tools/testing/selftests/x86/vsyscall_control.c
@@ -0,0 +1,891 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * vsyscall_lockout.c - check that disabling vsyscall works
+ * Copyright (C) 2021 Red Hat, Inc.
+ *
+ * This test requires vsyscall=xonly or vsyscall=emulate. With
+ * vsyscall=emulate, ARCH_VSYSCALL_CONTROL cannot turn off vsyscall
+ * completely (reads still work), but this is not tested here.
+ */
+
+#include <stddef.h>
+
+#include <asm/prctl.h>
+#include <asm/vsyscall.h>
+#include <linux/errno.h>
+#include <linux/fcntl.h>
+#include <linux/signal.h>
+#include <linux/time.h>
+#include <linux/types.h>
+#include <linux/unistd.h>
+
+#ifndef ARCH_VSYSCALL_CONTROL
+#define ARCH_VSYSCALL_CONTROL 0x5001
+#elif ARCH_VSYSCALL_CONTROL != 0x5001
+#error wrong vlaue for ARCH_VSYSCALL_CONTROL
+#endif
+
+
+static inline long syscall0(int nr)
+{
+ unsigned long result;
+
+ __asm__ volatile ("syscall"
+ : "=a" (result)
+ : "0" (nr)
+ : "memory", "cc", "r11", "cx");
+ return result;
+}
+
+static inline long syscall1(int nr, long arg0)
+{
+ register long rdi asm("rdi") = arg0;
+ unsigned long result;
+
+ __asm__ volatile ("syscall"
+ : "=a" (result)
+ : "0" (nr), "r" (rdi)
+ : "memory", "cc", "r11", "cx");
+ return result;
+}
+
+static inline long syscall2(int nr, long arg0, long arg1)
+{
+ register long rdi asm("rdi") = arg0;
+ register long rsi asm("rsi") = arg1;
+ unsigned long result;
+
+ __asm__ volatile ("syscall"
+ : "=a" (result)
+ : "0" (nr), "r" (rdi), "r" (rsi)
+ : "memory", "cc", "r11", "cx");
+ return result;
+}
+
+static inline long syscall3(int nr, long arg0, long arg1, long arg2)
+{
+ register long rdi asm("rdi") = arg0;
+ register long rsi asm("rsi") = arg1;
+ register long rdx asm("rdx") = arg2;
+ unsigned long result;
+
+ __asm__ volatile ("syscall"
+ : "=a" (result)
+ : "0" (nr), "r" (rdi), "r" (rsi), "r" (rdx)
+ : "memory", "cc", "r11", "cx");
+ return result;
+}
+
+static inline long syscall4(int nr, long arg0, long arg1, long arg2, long arg3)
+{
+ register long rdi asm("rdi") = arg0;
+ register long rsi asm("rsi") = arg1;
+ register long rdx asm("rdx") = arg2;
+ register long r10 asm("r10") = arg3;
+ unsigned long result;
+
+ __asm__ volatile ("syscall"
+ : "=a" (result)
+ : "0" (nr), "r" (rdi), "r" (rsi), "r" (rdx),
+ "r" (r10)
+ : "memory", "cc", "r11", "cx");
+ return result;
+}
+
+static inline long syscall5(int nr, long arg0, long arg1, long arg2, long arg3,
+ long arg4)
+{
+ register long rdi asm("rdi") = arg0;
+ register long rsi asm("rsi") = arg1;
+ register long rdx asm("rdx") = arg2;
+ register long r10 asm("r10") = arg3;
+ register long r8 asm("r8") = arg4;
+ unsigned long result;
+
+ __asm__ volatile ("syscall"
+ : "=a" (result)
+ : "0" (nr), "r" (rdi), "r" (rsi), "r" (rdx),
+ "r" (r10), "r" (r8)
+ : "memory", "cc", "r11", "cx");
+ return result;
+}
+
+static inline long vsyscall2(long addr, long arg0, long arg1)
+{
+ register long rdi asm("rdi") = arg0;
+ register long rsi asm("rsi") = arg1;
+ unsigned long result;
+
+ __asm__ volatile ("callq *%%rax"
+ : "=a" (result)
+ : "0" (addr), "r" (rdi), "r" (rsi)
+ : "memory", "cc", "r11", "cx");
+ return result;
+}
+
+static void __attribute__ ((noreturn)) sys_exit(int status)
+{
+ syscall1(__NR_exit, status);
+ __builtin_unreachable();
+}
+
+static int sys_access(const char *pathname, int mode)
+{
+ return syscall2(__NR_access, (long) pathname, mode);
+}
+
+static int sys_mkdir(const char *pathname, __kernel_mode_t mode)
+{
+ return syscall2(__NR_mkdir, (long) pathname, mode);
+}
+
+static int sys_open(const char *pathname, int flags, __kernel_mode_t mode)
+{
+ return syscall3(__NR_open, (long) pathname, flags, mode);
+}
+
+static long sys_read(int fd, void *buffer, size_t length)
+{
+ return syscall3(__NR_read, fd, (long) buffer, length);
+}
+
+static long sys_write(int fd, const void *buffer, size_t length)
+{
+ return syscall3(__NR_write, fd, (long) buffer, length);
+}
+
+static int sys_mount(const char *source, const char *pathname,
+ const char *fstype, unsigned long flags,
+ const void *data)
+{
+ return syscall5(__NR_mount, (long) source, (long) pathname,
+ (long) fstype, flags, (long) data);
+}
+
+static void sigabrt(void)
+{
+ syscall2(__NR_kill, syscall0(__NR_getpid), SIGABRT);
+}
+
+/*
+ * String buffers.
+ */
+
+struct buffer {
+ char *position;
+ char *limit;
+};
+
+static void buffer_init(struct buffer *b, char *start, size_t length)
+{
+ b->position = start;
+ b->limit = start + length;
+}
+
+static void buffer_append(struct buffer *b, char ch)
+{
+ if (b->position >= b->limit)
+ sigabrt();
+ *b->position = ch;
+ ++b->position;
+}
+
+static void buffer_append_string(struct buffer *b, const char *p)
+{
+ while (*p) {
+ buffer_append(b, *p);
+ ++p;
+ }
+}
+
+static void buffer_append_dec_1(struct buffer *b, unsigned long val)
+{
+ if (val != 0) {
+ buffer_append_dec_1(b, val / 10);
+ buffer_append(b, '0' + (val % 10));
+ }
+}
+
+static void buffer_append_dec(struct buffer *b, unsigned long val)
+{
+ if (val == 0) {
+ buffer_append(b, '0');
+ return;
+ }
+ buffer_append_dec_1(b, val);
+}
+
+/*
+ * Output to standard output.
+ */
+
+static void print_char(char byte)
+{
+ if (sys_write(1, &byte, 1) < 0)
+ sigabrt();
+}
+
+static void print_string(const char *p)
+{
+ while (*p) {
+ print_char(*p);
+ ++p;
+ }
+}
+
+static void print_dec_1(unsigned long val)
+{
+ if (val != 0) {
+ print_dec_1(val / 10);
+ print_char('0' + (val % 10));
+ }
+}
+
+static void print_dec(unsigned long val)
+{
+ if (val == 0)
+ print_char('0');
+ else
+ print_dec_1(val);
+}
+
+static void print_signed_dec(long val)
+{
+ if (val < 0) {
+ print_char('-');
+ print_dec(-(unsigned long)val);
+ } else
+ print_dec(val);
+}
+
+static void print_message(unsigned int lineno, const char *tag, const char *p)
+{
+ print_string(__FILE__);
+ print_char(':');
+ print_dec(lineno);
+ print_char(':');
+ print_char(' ');
+ print_string(tag);
+ print_char(':');
+ print_char(' ');
+ print_string(p);
+}
+
+static void print_info(unsigned int lineno, const char *p)
+{
+ print_message(lineno, "info", p);
+}
+
+static void print_error(unsigned int lineno, const char *p)
+{
+ print_message(lineno, "ERROR", p);
+}
+
+static void print_failure(int lineno, const char *label, long ret)
+{
+ print_error(lineno, label);
+ print_string(" failed: ");
+ print_signed_dec(ret);
+ print_char('\n');
+}
+
+static void print_time(int lineno, const char *label, struct timeval tv)
+{
+ print_info(lineno, label);
+ print_string(": ");
+ print_dec(tv.tv_sec);
+ print_char(' ');
+ print_dec(tv.tv_usec);
+ print_char('\n');
+}
+
+/*
+ * Process-failing (v)syscall wrappers.
+ */
+
+static void xgettimeofday(struct timeval *tv)
+{
+ long ret = syscall2(__NR_gettimeofday, (long) tv, 0);
+
+ if (ret != 0) {
+ print_failure(__LINE__, "gettimeofday", ret);
+ sigabrt();
+ }
+}
+
+static void xvgettimeofday(struct timeval *tv)
+{
+ long ret = vsyscall2(VSYSCALL_ADDR, (long) tv, 0);
+
+ if (ret) {
+ print_failure(__LINE__, "vgettimeofday", ret);
+ sigabrt();
+ }
+}
+
+static int sys_arch_prctl(int code, unsigned long addr)
+{
+ return syscall2(__NR_arch_prctl, code, addr);
+}
+
+static void xclose(int fd)
+{
+ long ret = syscall1(__NR_close, fd);
+
+ if (ret < 0) {
+ print_failure(__LINE__, "close", ret);
+ sigabrt();
+ }
+}
+
+static void xwrite_byte(int fd, char b)
+{
+ long ret = sys_write(fd, &b, 1);
+
+ if (ret != 1) {
+ print_failure(__LINE__, "write", ret);
+ sigabrt();
+ }
+}
+
+static int xread_byte(int fd)
+{
+ char b;
+ long ret = sys_read(fd, &b, 1);
+
+ if (ret != 1) {
+ print_failure(__LINE__, "read", ret);
+ sigabrt();
+ }
+ return b;
+}
+
+static void xpipe(int fds[static 2])
+{
+ long ret = syscall2(__NR_pipe2, (long) fds, O_CLOEXEC);
+
+ if (ret != 0) {
+ print_failure(__LINE__, "pipe2", ret);
+ sigabrt();
+ }
+}
+
+static __kernel_pid_t xfork(void)
+{
+ long ret = syscall0(__NR_fork);
+
+ if (ret < 0) {
+ print_failure(__LINE__, "fork", ret);
+ sigabrt();
+ }
+ return ret;
+}
+
+static void xexecve(const char *pathname, char **argv, char **envp)
+{
+ long ret;
+
+ ret = syscall3(__NR_execve, (long) pathname, (long) argv, (long) envp);
+ print_failure(__LINE__, "execve", ret);
+ sigabrt();
+}
+
+static __kernel_pid_t xwaitpid(__kernel_pid_t pid, int *status, int options)
+{
+ long ret = syscall4(__NR_wait4, pid, (long) status, options, 0);
+
+ if (ret < 0) {
+ print_failure(__LINE__, "wait4", ret);
+ sigabrt();
+ }
+ return ret;
+}
+
+/*
+ * Various helpers.
+ */
+
+static void vsyscall_disable(void)
+{
+ long ret = sys_arch_prctl(ARCH_VSYSCALL_CONTROL, 0);
+
+ if (ret != 0)
+ print_failure(__LINE__, "arch_prctl(ARCH_VSYSCALL_CONTROL, 0)", ret);
+}
+
+static void vsyscall_enable(void)
+{
+ long ret = sys_arch_prctl(ARCH_VSYSCALL_CONTROL, 1);
+
+ if (ret != 0)
+ print_failure(__LINE__, "arch_prctl(ARCH_VSYSCALL_CONTROL, 1)", ret);
+}
+
+static long difftime(struct timeval first, struct timeval second)
+{
+ return second.tv_usec - first.tv_usec +
+ (second.tv_sec - first.tv_sec) * 1000 * 1000;
+}
+
+static void ensure_proc_is_mounted(int *status)
+{
+ int ret;
+
+ if (sys_access("/proc/version", 0) == 0)
+ return;
+
+ ret = sys_mkdir("/proc", 0555);
+ if (ret == EEXIST)
+ return;
+ if (ret != 0) {
+ print_failure(__LINE__, "could not create /proc", ret);
+ *status = 1;
+ return;
+ }
+ ret = sys_mount("none", "/proc", "proc", 0, NULL);
+ if (ret != 0) {
+ print_failure(__LINE__, "could not mount /proc", ret);
+ *status = 1;
+ return;
+ }
+ if (sys_access("/proc/version", 0) != 0) {
+ print_error(__LINE__, "no /proc/version after mounting /proc");
+ *status = 1;
+ return;
+ }
+}
+
+/*
+ * Individual subtest functions.
+ */
+
+static void check_time(int *status)
+{
+ struct timeval initial_time = { -1, -1 };
+ struct timeval vsyscall_time = { -1, -1 };
+ struct timeval final_time = { -1, -1 };
+ long vsyscall_diff, final_diff;
+
+ xgettimeofday(&initial_time);
+ xvgettimeofday(&vsyscall_time);
+ xgettimeofday(&final_time);
+ vsyscall_diff = difftime(initial_time, vsyscall_time);
+ final_diff = difftime(vsyscall_time, final_time);
+
+ print_time(__LINE__, "initial gettimeofday", initial_time);
+ print_time(__LINE__, "vsyscall gettimeofday", vsyscall_time);
+ print_time(__LINE__, "final gettimeofday", final_time);
+
+ if (initial_time.tv_sec < 0 || initial_time.tv_usec < 0 ||
+ vsyscall_time.tv_sec < 0 || vsyscall_time.tv_usec < 0 ||
+ final_time.tv_sec < 0 || final_time.tv_usec < 0) {
+ print_error(__LINE__, "negative time\n");
+ *status = 1;
+ }
+
+ print_info(__LINE__, "differences: ");
+ print_signed_dec(vsyscall_diff);
+ print_char(' ');
+ print_signed_dec(final_diff);
+ print_char('\n');
+
+ if (vsyscall_diff < 0 || final_diff < 0) {
+ /*
+ * This may produce false positives if there is an active NTP.
+ */
+ print_error(__LINE__, "time went backwards\n");
+ *status = 1;
+ }
+}
+
+static void check_lockout_after_fork(int *status, int twice)
+{
+ __kernel_pid_t pid;
+ struct timeval vsyscall_time;
+ int wstatus;
+
+ if (twice) {
+ __kernel_pid_t pid_outer;
+
+ print_info(__LINE__, "checking that lockout is inherited by fork\n");
+
+ pid_outer = xfork();
+ if (pid_outer == 0) {
+ vsyscall_disable();
+ /*
+ * Logic for the subprocess follows below.
+ */
+ } else {
+ xwaitpid(pid_outer, &wstatus, 0);
+ if (wstatus != 0) {
+ print_error(__LINE__, "unexpected exit status: ");
+ print_signed_dec(wstatus);
+ print_char('\n');
+ *status = 1;
+ }
+ return;
+ }
+ } else
+ print_info(__LINE__, "checking that lockout works after one fork\n");
+
+ pid = xfork();
+ if (pid == 0) {
+ if (!twice)
+ vsyscall_disable();
+ /*
+ * This should trigger a fault.
+ */
+ xvgettimeofday(&vsyscall_time);
+ sys_exit(0);
+ }
+ xwaitpid(pid, &wstatus, 0);
+ switch (wstatus) {
+ case 0:
+ print_error(__LINE__, "no crash after lockout\n");
+ *status = 1;
+ break;
+ case 0x0100:
+ *status = 1;
+ break;
+ case SIGSEGV:
+ print_info(__LINE__, "termination after lockout\n");
+ break;
+ default:
+ print_error(__LINE__, "unexpected exit status: ");
+ print_signed_dec(wstatus);
+ print_char('\n');
+ *status = 1;
+ }
+
+ if (twice)
+ sys_exit(*status);
+
+ /*
+ * Status in the parent process should be unaffected.
+ */
+ xvgettimeofday(&vsyscall_time);
+}
+
+static void check_no_lockout_after_enable(int *status)
+{
+ __kernel_pid_t pid;
+ struct timeval vsyscall_time;
+ int wstatus;
+
+ print_info(__LINE__, "checking that vsyscall can be re-enabled\n");
+
+ pid = xfork();
+ if (pid == 0) {
+ vsyscall_disable();
+ vsyscall_enable();
+ xvgettimeofday(&vsyscall_time);
+ print_time(__LINE__, "vsyscall time after re-enable", vsyscall_time);
+ sys_exit(0);
+ }
+
+ xwaitpid(pid, &wstatus, 0);
+ if (wstatus != 0) {
+ print_error(__LINE__, "unexpected exit status: ");
+ print_signed_dec(wstatus);
+ print_char('\n');
+ *status = 1;
+ }
+}
+
+static void check_no_lockout_after_execve(char **argv, int *status)
+{
+ __kernel_pid_t pid;
+ int wstatus;
+
+ print_info(__LINE__, "checking that lockout is not inherited by execve\n");
+ pid = xfork();
+ if (pid == 0) {
+ struct timeval vsyscall_time;
+ char *new_argv[3];
+
+ xvgettimeofday(&vsyscall_time);
+ vsyscall_disable();
+
+ /*
+ * Re-exec the second stage. See main_2 below.
+ */
+ new_argv[0] = argv[0];
+ new_argv[1] = "2";
+ new_argv[2] = NULL;
+ xexecve(argv[0], new_argv, new_argv + 2);
+ }
+
+ xwaitpid(pid, &wstatus, 0);
+ if (wstatus != 0) {
+ print_error(__LINE__, "unexpected exit status: ");
+ print_signed_dec(wstatus);
+ print_char('\n');
+ *status = 1;
+ }
+}
+
+static int has_vsyscall_map(int pid, int *status)
+{
+ int result = 0;
+ char maps_path[50];
+ int fd;
+
+ /*
+ * Construct /proc/PID/maps path.
+ */
+ {
+ struct buffer b;
+
+ buffer_init(&b, maps_path, sizeof(maps_path));
+ buffer_append_string(&b, "/proc/");
+ if (pid == 0)
+ buffer_append_string(&b, "self");
+ else
+ buffer_append_dec(&b, pid);
+ buffer_append_string(&b, "/maps");
+ buffer_append(&b, 0);
+ }
+
+ fd = sys_open(maps_path, O_RDONLY, 0);
+ if (fd < 0) {
+ print_error(__LINE__, "maps file ");
+ print_string(maps_path);
+ print_string(": ");
+ print_signed_dec(fd);
+ print_char('\n');
+ *status = 1;
+ }
+
+ /*
+ * Search for "[vsyscall]\n".
+ */
+ {
+ char buf[4096];
+ long ret;
+
+ for (size_t i = 0; i < sizeof(buf); ++i)
+ buf[i] = 0;
+ ret = sys_read(fd, buf, sizeof(buf));
+
+ if (ret < 0 || ret >= sizeof(buf))
+ print_failure(__LINE__, "read", ret);
+ else {
+ char *bracket = buf;
+
+ while (1) {
+ while (*bracket && *bracket != '[')
+ ++bracket;
+ if (*bracket != '[')
+ /*
+ * End of file has been reached.
+ */
+ break;
+ ++bracket;
+ if (bracket[0] == 'v'
+ && bracket[1] == 's'
+ && bracket[2] == 'y'
+ && bracket[3] == 's'
+ && bracket[4] == 'c'
+ && bracket[5] == 'a'
+ && bracket[6] == 'l'
+ && bracket[7] == 'l'
+ && bracket[8] == ']'
+ && bracket[9] == '\n') {
+ result = 1;
+ break;
+ }
+ }
+ }
+ }
+
+ xclose(fd);
+ return result;
+}
+
+static void check_vsyscall_in_self_maps(int *status)
+{
+ __kernel_pid_t pid;
+ int wstatus;
+
+ print_info(__LINE__, "checking [vsyscall] in /proc/self/maps\n");
+
+ pid = xfork();
+ if (pid == 0) {
+ if (!has_vsyscall_map(0, status)) {
+ print_error(__LINE__, "[vsyscall] missing\n");
+ *status = 1;
+ }
+ vsyscall_disable();
+ if (has_vsyscall_map(0, status)) {
+ print_error(__LINE__, "[vsyscall] present after disable\n");
+ *status = 1;
+ }
+ vsyscall_enable();
+ if (!has_vsyscall_map(0, status)) {
+ print_error(__LINE__, "[vsyscall] missing after enable\n");
+ *status = 1;
+ }
+ sys_exit(*status);
+ }
+
+ xwaitpid(pid, &wstatus, 0);
+ if (wstatus != 0) {
+ print_error(__LINE__, "unexpected exit status: ");
+ print_signed_dec(wstatus);
+ print_char('\n');
+ *status = 1;
+ }
+}
+
+static void check_vsyscall_maps_for_subprocess(int *status)
+{
+ __kernel_pid_t pid;
+ int wstatus;
+ int outer_to_inner[2];
+ int inner_to_outer[2];
+
+ /*
+ * Create pipes used to synchronize the two processes.
+ */
+ xpipe(outer_to_inner);
+ xpipe(inner_to_outer);
+
+ print_info(__LINE__, "checking [vsyscall] in /proc/PID/maps\n");
+
+ pid = xfork();
+ if (pid == 0) {
+ xclose(outer_to_inner[1]);
+ xclose(inner_to_outer[0]);
+
+ xread_byte(outer_to_inner[0]);
+ vsyscall_disable();
+ xwrite_byte(inner_to_outer[1], 101);
+
+ xread_byte(outer_to_inner[0]);
+ vsyscall_disable();
+ xwrite_byte(inner_to_outer[1], 102);
+
+ sys_exit(0);
+ }
+
+ xclose(outer_to_inner[0]);
+ xclose(inner_to_outer[1]);
+
+ if (!has_vsyscall_map(pid, status)) {
+ print_error(__LINE__, "subprocess starts without [vsyscall]");
+ *status = 1;
+ }
+
+ xwrite_byte(outer_to_inner[1], 1);
+ xread_byte(inner_to_outer[0]);
+
+ if (has_vsyscall_map(pid, status)) {
+ print_error(__LINE__, "subprocess has [vsyscall] after disable");
+ *status = 1;
+ }
+
+ xwrite_byte(outer_to_inner[1], 2);
+ xread_byte(inner_to_outer[0]);
+
+ if (has_vsyscall_map(pid, status)) {
+ print_error(__LINE__, "subprocess lacks [vsyscall] after enable");
+ *status = 1;
+ }
+
+ xclose(outer_to_inner[1]);
+ xclose(inner_to_outer[0]);
+
+ xwaitpid(pid, &wstatus, 0);
+ if (wstatus != 0) {
+ print_error(__LINE__, "unexpected exit status: ");
+ print_signed_dec(wstatus);
+ print_char('\n');
+ *status = 1;
+ }
+}
+
+static void check_einval(int *status)
+{
+ long ret;
+
+ ret = sys_arch_prctl(ARCH_VSYSCALL_CONTROL, 2);
+ if (ret != -EINVAL) {
+ print_error(__LINE__, "arch_prctl(ARCH_VSYSCALL_CONTROL, 2) returned ");
+ print_signed_dec(ret);
+ print_char('\n');
+ *status = 1;
+ }
+}
+
+/*
+ * Second stage: Check that the lockout is not inherited across execve.
+ * Used from check_no_lockout_after_execve.
+ */
+static int main_2(void)
+{
+ struct timeval vsyscall_time = { -1, -1 };
+ int status = 0;
+
+ xvgettimeofday(&vsyscall_time);
+ print_time(__LINE__, "vsyscall gettimeofday after fork", vsyscall_time);
+ if (vsyscall_time.tv_sec < 0 || vsyscall_time.tv_usec < 0)
+ status = 1;
+
+ return status;
+}
+
+static int main(int argc, char **argv)
+{
+ int status = 0;
+
+ if (argc > 1) {
+ switch (*argv[1]) {
+ case '2':
+ return main_2();
+ default:
+ print_string("usage: ");
+ print_string(argv[0]);
+ print_string("\n");
+ return 1;
+ }
+ }
+
+ ensure_proc_is_mounted(&status);
+
+ if (has_vsyscall_map(0, &status))
+ print_info(__LINE__, "vsyscall active at process start\n");
+ else
+ print_error(__LINE__, "vsyscall inactive at process start\n");
+
+
+ check_time(&status);
+ check_lockout_after_fork(&status, 0);
+ check_lockout_after_fork(&status, 1);
+ check_no_lockout_after_enable(&status);
+ check_no_lockout_after_execve(argv, &status);
+ check_vsyscall_in_self_maps(&status);
+ check_vsyscall_maps_for_subprocess(&status);
+ check_einval(&status);
+
+ print_info(__LINE__, "testing done, exit status: ");
+ print_signed_dec(status);
+ print_char('\n');
+ return status;
+}
+
+static void __attribute__ ((used)) main_trampoline(long *rsp)
+{
+ sys_exit(main(*rsp, (char **) (rsp + 1)));
+}
+
+__asm__(".text\n\t"
+ ".globl _start\n"
+ "_start:\n\t"
+ ".cfi_startproc\n\t"
+ ".cfi_undefined rip\n\t"
+ "movq %rsp, %rdi\n\t"
+ "callq main_trampoline\n\t" /* Results in psABI %rsp alignment. */
+ ".cfi_endproc\n\t"
+ ".type _start, @function\n\t"
+ ".size _start, . - _start\n\t"
+ ".previous");
--
2.33.1
^ permalink raw reply related
* [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
From: Florian Weimer @ 2022-01-05 16:03 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-arch, Linux API, linux-x86_64, kernel-hardening, linux-mm,
the arch/x86 maintainers, musl, libc-alpha, linux-kernel,
Dave Hansen, Kees Cook, Andrei Vagin
In-Reply-To: <3a1c8280967b491bf6917a18fbff6c9b52e8df24.1641398395.git.fweimer@redhat.com>
And avoid compiling PCHs by accident.
Signed-off-by: Florian Weimer <fweimer@redhat.com>
---
v3: Patch split out.
tools/testing/selftests/x86/Makefile | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile
index 8a1f62ab3c8e..0993d12f2c38 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -72,10 +72,12 @@ all_64: $(BINARIES_64)
EXTRA_CLEAN := $(BINARIES_32) $(BINARIES_64)
$(BINARIES_32): $(OUTPUT)/%_32: %.c helpers.h
- $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl -lm
+ $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $(filter-out %.h, $^) \
+ $(or $(LIBS), -lrt -ldl -lm)
$(BINARIES_64): $(OUTPUT)/%_64: %.c helpers.h
- $(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
+ $(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $(filter-out %.h, $^) \
+ $(or $(LIBS), -lrt -ldl -lm)
# x86_64 users should be encouraged to install 32-bit libraries
ifeq ($(CAN_BUILD_I386)$(CAN_BUILD_X86_64),01)
--
2.33.1
^ permalink raw reply related
* Re: [PATCH v5 4/6] drm/i915: Use vma resources for async unbinding
From: Thomas Hellström @ 2022-01-05 16:03 UTC (permalink / raw)
To: Matthew Auld, intel-gfx, dri-devel
In-Reply-To: <f022f46f-555f-ec83-49a9-df771e46127c@intel.com>
On Wed, 2022-01-05 at 15:52 +0000, Matthew Auld wrote:
> On 04/01/2022 12:51, Thomas Hellström wrote:
> > Implement async (non-blocking) unbinding by not syncing the vma
> > before
> > calling unbind on the vma_resource.
> > Add the resulting unbind fence to the object's dma_resv from where
> > it is
> > picked up by the ttm migration code.
> > Ideally these unbind fences should be coalesced with the migration
> > blit
> > fence to avoid stalling the migration blit waiting for unbind, as
> > they
> > can certainly go on in parallel, but since we don't yet have a
> > reasonable data structure to use to coalesce fences and attach the
> > resulting fence to a timeline, we defer that for now.
> >
> > Note that with async unbinding, even while the unbind waits for the
> > preceding bind to complete before unbinding, the vma itself might
> > have been
> > destroyed in the process, clearing the vma pages. Therefore we can
> > only allow async unbinding if we have a refcounted sg-list and keep
> > a
> > refcount on that for the vma resource pages to stay intact until
> > binding occurs. If this condition is not met, a request for an
> > async
> > unbind is diverted to a sync unbind.
> >
> > v2:
> > - Use a separate kmem_cache for vma resources for now to isolate
> > their
> > memory allocation and aid debugging.
> > - Move the check for vm closed to the actual unbinding thread.
> > Regardless
> > of whether the vm is closed, we need the unbind fence to
> > properly wait
> > for capture.
> > - Clear vma_res::vm on unbind and update its documentation.
> > v4:
> > - Take cache coloring into account when searching for vma resources
> > pending unbind. (Matthew Auld)
> > v5:
> > - Fix timeout and error check in
> > i915_vma_resource_bind_dep_await().
> > - Avoid taking a reference on the object for async binding if
> > async unbind capable.
> > - Fix braces around a single-line if statement.
> >
> > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>
> <snip>
>
> > @@ -434,12 +439,30 @@ int i915_vma_bind(struct i915_vma *vma,
> >
> > bind_flags &= ~vma_flags;
> > if (bind_flags == 0) {
> > - kfree(vma_res);
> > + i915_vma_resource_free(vma_res);
> > return 0;
> > }
> >
> > GEM_BUG_ON(!atomic_read(&vma->pages_count));
> >
> > + /* Wait for or await async unbinds touching our range */
> > + if (work && bind_flags & vma->vm->bind_async_flags)
> > + ret = i915_vma_resource_bind_dep_await(vma->vm,
> > + &work-
> > >base.chain,
> > + vma-
> > >node.start,
> > + vma-
> > >node.size,
> > + true,
> > + GFP_NOWAIT |
> > +
> > __GFP_RETRY_MAYFAIL |
> > +
> > __GFP_NOWARN);
> > + else
> > + ret = i915_vma_resource_bind_dep_sync(vma->vm, vma-
> > >node.start,
> > + vma-
> > >node.size, true);
> > + if (ret) {
> > + i915_vma_resource_free(vma_res);
> > + return ret;
> > + }
> > +
> > if (vma->resource || !vma_res) {
> > /* Rebinding with an additional I915_VMA_*_BIND */
> > GEM_WARN_ON(!vma_flags);
> > @@ -452,9 +475,11 @@ int i915_vma_bind(struct i915_vma *vma,
> > if (work && bind_flags & vma->vm->bind_async_flags) {
> > struct dma_fence *prev;
> >
> > - work->vma = vma;
> > + work->vma_res = i915_vma_resource_get(vma-
> > >resource);
> > work->cache_level = cache_level;
> > work->flags = bind_flags;
> > + if (vma->obj->mm.rsgt)
> > + work->rsgt = i915_refct_sgt_get(vma->obj-
> > >mm.rsgt);
>
> Hmmm, at a glance I would have expected this to use the vma->pages. I
> think with the GGTT the vma will often create its own sg layout which
> !=
> obj->mm.sgt. IIUC the async unbind will still call vma_unbind_pages
> which might nuke the vma sgt? Or is something else going on here?
>
Yes, the binding code is only using vma_res->pages, which should have
been copied from vma->pages, and keeps a reference to the rsgt just in
case we do an async unbind.
However good point we should refuse async unbind for now if vma_res-
>pages != &rsgt->table, because the former might otherwise be nuked
before the async unbind actually happens. Will fix that for next
version.
/Thomas
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v5 4/6] drm/i915: Use vma resources for async unbinding
From: Thomas Hellström @ 2022-01-05 16:03 UTC (permalink / raw)
To: Matthew Auld, intel-gfx, dri-devel
In-Reply-To: <f022f46f-555f-ec83-49a9-df771e46127c@intel.com>
On Wed, 2022-01-05 at 15:52 +0000, Matthew Auld wrote:
> On 04/01/2022 12:51, Thomas Hellström wrote:
> > Implement async (non-blocking) unbinding by not syncing the vma
> > before
> > calling unbind on the vma_resource.
> > Add the resulting unbind fence to the object's dma_resv from where
> > it is
> > picked up by the ttm migration code.
> > Ideally these unbind fences should be coalesced with the migration
> > blit
> > fence to avoid stalling the migration blit waiting for unbind, as
> > they
> > can certainly go on in parallel, but since we don't yet have a
> > reasonable data structure to use to coalesce fences and attach the
> > resulting fence to a timeline, we defer that for now.
> >
> > Note that with async unbinding, even while the unbind waits for the
> > preceding bind to complete before unbinding, the vma itself might
> > have been
> > destroyed in the process, clearing the vma pages. Therefore we can
> > only allow async unbinding if we have a refcounted sg-list and keep
> > a
> > refcount on that for the vma resource pages to stay intact until
> > binding occurs. If this condition is not met, a request for an
> > async
> > unbind is diverted to a sync unbind.
> >
> > v2:
> > - Use a separate kmem_cache for vma resources for now to isolate
> > their
> > memory allocation and aid debugging.
> > - Move the check for vm closed to the actual unbinding thread.
> > Regardless
> > of whether the vm is closed, we need the unbind fence to
> > properly wait
> > for capture.
> > - Clear vma_res::vm on unbind and update its documentation.
> > v4:
> > - Take cache coloring into account when searching for vma resources
> > pending unbind. (Matthew Auld)
> > v5:
> > - Fix timeout and error check in
> > i915_vma_resource_bind_dep_await().
> > - Avoid taking a reference on the object for async binding if
> > async unbind capable.
> > - Fix braces around a single-line if statement.
> >
> > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>
> <snip>
>
> > @@ -434,12 +439,30 @@ int i915_vma_bind(struct i915_vma *vma,
> >
> > bind_flags &= ~vma_flags;
> > if (bind_flags == 0) {
> > - kfree(vma_res);
> > + i915_vma_resource_free(vma_res);
> > return 0;
> > }
> >
> > GEM_BUG_ON(!atomic_read(&vma->pages_count));
> >
> > + /* Wait for or await async unbinds touching our range */
> > + if (work && bind_flags & vma->vm->bind_async_flags)
> > + ret = i915_vma_resource_bind_dep_await(vma->vm,
> > + &work-
> > >base.chain,
> > + vma-
> > >node.start,
> > + vma-
> > >node.size,
> > + true,
> > + GFP_NOWAIT |
> > +
> > __GFP_RETRY_MAYFAIL |
> > +
> > __GFP_NOWARN);
> > + else
> > + ret = i915_vma_resource_bind_dep_sync(vma->vm, vma-
> > >node.start,
> > + vma-
> > >node.size, true);
> > + if (ret) {
> > + i915_vma_resource_free(vma_res);
> > + return ret;
> > + }
> > +
> > if (vma->resource || !vma_res) {
> > /* Rebinding with an additional I915_VMA_*_BIND */
> > GEM_WARN_ON(!vma_flags);
> > @@ -452,9 +475,11 @@ int i915_vma_bind(struct i915_vma *vma,
> > if (work && bind_flags & vma->vm->bind_async_flags) {
> > struct dma_fence *prev;
> >
> > - work->vma = vma;
> > + work->vma_res = i915_vma_resource_get(vma-
> > >resource);
> > work->cache_level = cache_level;
> > work->flags = bind_flags;
> > + if (vma->obj->mm.rsgt)
> > + work->rsgt = i915_refct_sgt_get(vma->obj-
> > >mm.rsgt);
>
> Hmmm, at a glance I would have expected this to use the vma->pages. I
> think with the GGTT the vma will often create its own sg layout which
> !=
> obj->mm.sgt. IIUC the async unbind will still call vma_unbind_pages
> which might nuke the vma sgt? Or is something else going on here?
>
Yes, the binding code is only using vma_res->pages, which should have
been copied from vma->pages, and keeps a reference to the rsgt just in
case we do an async unbind.
However good point we should refuse async unbind for now if vma_res-
>pages != &rsgt->table, because the former might otherwise be nuked
before the async unbind actually happens. Will fix that for next
version.
/Thomas
^ permalink raw reply
* [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
From: Florian Weimer @ 2022-01-05 16:02 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-arch, Linux API, linux-x86_64, kernel-hardening, linux-mm,
the arch/x86 maintainers, musl, libc-alpha, linux-kernel,
Dave Hansen, Kees Cook, Andrei Vagin
Distributions struggle with changing the default for vsyscall
emulation because it is a clear break of userspace ABI, something
that should not happen.
The legacy vsyscall interface is supposed to be used by libcs only,
not by applications. This commit adds a new arch_prctl request,
ARCH_VSYSCALL_CONTROL, with one argument. If the argument is 0,
executing vsyscalls will cause the process to terminate. Argument 1
turns vsyscall back on (this is mostly for a largely theoretical
CRIU use case).
Newer libcs can use a zero ARCH_VSYSCALL_CONTROL at startup to disable
vsyscall for the process. Legacy libcs do not perform this call, so
vsyscall remains enabled for them. This approach should achieves
backwards compatibility (perfect compatibility if the assumption that
only libcs use vsyscall is accurate), and it provides full hardening
for new binaries.
The chosen value of ARCH_VSYSCALL_CONTROL should avoid conflicts
with other x86-64 arch_prctl requests. The fact that with
vsyscall=emulate, reading the vsyscall region is still possible
even after a zero ARCH_VSYSCALL_CONTROL is considered limitation
in the current implementation and may change in a future kernel
version.
Future arch_prctls requests commonly used at process startup can imply
ARCH_VSYSCALL_CONTROL with a zero argument, so that a separate system
call for disabling vsyscall is avoided.
Signed-off-by: Florian Weimer <fweimer@redhat.com>
Acked-by: Andrei Vagin <avagin@gmail.com>
---
v3: Remove warning log message. Split out test.
v2: ARCH_VSYSCALL_CONTROL instead of ARCH_VSYSCALL_LOCKOUT. New tests
for the toggle behavior. Implement hiding [vsyscall] in
/proc/PID/maps and test it. Various other test fixes cleanups
(e.g., fixed missing second argument to gettimeofday).
arch/x86/entry/vsyscall/vsyscall_64.c | 7 ++++++-
arch/x86/include/asm/mmu.h | 6 ++++++
arch/x86/include/uapi/asm/prctl.h | 2 ++
arch/x86/kernel/process_64.c | 7 +++++++
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index fd2ee9408e91..6fc524b9f232 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -174,6 +174,9 @@ bool emulate_vsyscall(unsigned long error_code,
tsk = current;
+ if (tsk->mm->context.vsyscall_disabled)
+ goto sigsegv;
+
/*
* Check for access_ok violations and find the syscall nr.
*
@@ -316,8 +319,10 @@ static struct vm_area_struct gate_vma __ro_after_init = {
struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
{
+ if (!mm || mm->context.vsyscall_disabled)
+ return NULL;
#ifdef CONFIG_COMPAT
- if (!mm || !(mm->context.flags & MM_CONTEXT_HAS_VSYSCALL))
+ if (!(mm->context.flags & MM_CONTEXT_HAS_VSYSCALL))
return NULL;
#endif
if (vsyscall_mode == NONE)
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 5d7494631ea9..3934d6907910 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -41,6 +41,12 @@ typedef struct {
#ifdef CONFIG_X86_64
unsigned short flags;
#endif
+#ifdef CONFIG_X86_VSYSCALL_EMULATION
+ /*
+ * Changed by arch_prctl(ARCH_VSYSCALL_CONTROL).
+ */
+ bool vsyscall_disabled;
+#endif
struct mutex lock;
void __user *vdso; /* vdso base address */
diff --git a/arch/x86/include/uapi/asm/prctl.h b/arch/x86/include/uapi/asm/prctl.h
index 754a07856817..aad0bcfbf49f 100644
--- a/arch/x86/include/uapi/asm/prctl.h
+++ b/arch/x86/include/uapi/asm/prctl.h
@@ -18,4 +18,6 @@
#define ARCH_MAP_VDSO_32 0x2002
#define ARCH_MAP_VDSO_64 0x2003
+#define ARCH_VSYSCALL_CONTROL 0x5001
+
#endif /* _ASM_X86_PRCTL_H */
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3402edec236c..834bad068211 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -816,6 +816,13 @@ long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2)
ret = put_user(base, (unsigned long __user *)arg2);
break;
}
+#ifdef CONFIG_X86_VSYSCALL_EMULATION
+ case ARCH_VSYSCALL_CONTROL:
+ if (unlikely(arg2 > 1))
+ return -EINVAL;
+ current->mm->context.vsyscall_disabled = !arg2;
+ break;
+#endif
#ifdef CONFIG_CHECKPOINT_RESTORE
# ifdef CONFIG_X86_X32_ABI
base-commit: c9e6606c7fe92b50a02ce51dda82586ebdf99b48
--
2.33.1
^ permalink raw reply related
* Re: [PATCH 1/4] drm/i915: don't call free_mmap_offset when purging
From: Matthew Auld @ 2022-01-05 16:03 UTC (permalink / raw)
To: Thomas Hellström, intel-gfx; +Cc: dri-devel
In-Reply-To: <43a8417d35c42bdb6aa0a11f72d7330eb14bdebe.camel@linux.intel.com>
On 05/01/2022 15:46, Thomas Hellström wrote:
> On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
>> The TTM backend is in theory the only user here(also purge should
>> only
>> be called once we have dropped the pages), where it is setup at
>> object
>> creation and is only removed once the object is destroyed. Also
>> resetting the node here might be iffy since the ttm fault handler
>> uses the stored fake offset to determine the page offset within the
>> pages
>> array.
>>
>> This also blows up in the dontneed-before-mmap test, since the
>> expectation is that the vma_node will live on, until the object is
>> destroyed:
>>
>> <2> [749.062902] kernel BUG at
>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:943!
>> <4> [749.062923] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
>> <4> [749.062928] CPU: 0 PID: 1643 Comm: gem_madvise Tainted: G U
>> W 5.16.0-rc8-CI-CI_DRM_11046+ #1
>> <4> [749.062933] Hardware name: Gigabyte Technology Co., Ltd. GB-Z390
>> Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019
>> <4> [749.062937] RIP: 0010:i915_ttm_mmap_offset.cold.35+0x5b/0x5d
>> [i915]
>> <4> [749.063044] Code: 00 48 c7 c2 a0 23 4e a0 48 c7 c7 26 df 4a a0
>> e8 95 1d d0 e0 bf 01 00 00 00 e8 8b ec cf e0 31 f6 bf 09 00 00 00 e8
>> 5f 30 c0 e0 <0f> 0b 48 c7 c1 24 4b 56 a0 ba 5b 03 00 00 48 c7 c6 c0
>> 23 4e a0 48
>> <4> [749.063052] RSP: 0018:ffffc90002ab7d38 EFLAGS: 00010246
>> <4> [749.063056] RAX: 0000000000000240 RBX: ffff88811f2e61c0 RCX:
>> 0000000000000006
>> <4> [749.063060] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
>> 0000000000000009
>> <4> [749.063063] RBP: ffffc90002ab7e58 R08: 0000000000000001 R09:
>> 0000000000000001
>> <4> [749.063067] R10: 000000000123d0f8 R11: ffffc90002ab7b20 R12:
>> ffff888112a1a000
>> <4> [749.063071] R13: 0000000000000004 R14: ffff88811f2e61c0 R15:
>> ffff888112a1a000
>> <4> [749.063074] FS: 00007f6e5fcad500(0000)
>> GS:ffff8884ad600000(0000) knlGS:0000000000000000
>> <4> [749.063078] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> <4> [749.063081] CR2: 00007efd264e39f0 CR3: 0000000115fd6005 CR4:
>> 00000000003706f0
>> <4> [749.063085] Call Trace:
>> <4> [749.063087] <TASK>
>> <4> [749.063089] __assign_mmap_offset+0x41/0x300 [i915]
>> <4> [749.063171] __assign_mmap_offset_handle+0x159/0x270 [i915]
>> <4> [749.063248] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
>> <4> [749.063325] drm_ioctl_kernel+0xae/0x140
>> <4> [749.063330] drm_ioctl+0x201/0x3d0
>> <4> [749.063333] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
>> <4> [749.063409] ? do_user_addr_fault+0x200/0x670
>> <4> [749.063415] __x64_sys_ioctl+0x6d/0xa0
>> <4> [749.063419] do_syscall_64+0x3a/0xb0
>> <4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae
>> <4> [749.063428] RIP: 0033:0x7f6e5f100317
>>
>> Testcase: igt@gem_madvise@dontneed-before-mmap
>> Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> index 89b70f5cde7a..9f429ed6e78a 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> @@ -161,7 +161,6 @@ int i915_gem_object_pin_pages_unlocked(struct
>> drm_i915_gem_object *obj)
>> /* Immediately discard the backing storage */
>> int i915_gem_object_truncate(struct drm_i915_gem_object *obj)
>> {
>> - drm_gem_free_mmap_offset(&obj->base);
>
> What happens if a non-ttm shmem system object gets truncated from the
> shrinker and then tries to use the above mmap offset?
AFAIK nothing on integrated is really using this. The mmap_offset ioctl
stuff is managing multiple vma nodes itself, per object(one for each
cache type/mapping or something), and so doesn't use this. And the shmem
mmap ioctl doesn't use the any fake offset stuff, AFAIK.
>
> /Thomas
>
>
>
>> if (obj->ops->truncate)
>> return obj->ops->truncate(obj);
>>
>
>
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 1/4] drm/i915: don't call free_mmap_offset when purging
From: Matthew Auld @ 2022-01-05 16:03 UTC (permalink / raw)
To: Thomas Hellström, intel-gfx; +Cc: dri-devel
In-Reply-To: <43a8417d35c42bdb6aa0a11f72d7330eb14bdebe.camel@linux.intel.com>
On 05/01/2022 15:46, Thomas Hellström wrote:
> On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
>> The TTM backend is in theory the only user here(also purge should
>> only
>> be called once we have dropped the pages), where it is setup at
>> object
>> creation and is only removed once the object is destroyed. Also
>> resetting the node here might be iffy since the ttm fault handler
>> uses the stored fake offset to determine the page offset within the
>> pages
>> array.
>>
>> This also blows up in the dontneed-before-mmap test, since the
>> expectation is that the vma_node will live on, until the object is
>> destroyed:
>>
>> <2> [749.062902] kernel BUG at
>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:943!
>> <4> [749.062923] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
>> <4> [749.062928] CPU: 0 PID: 1643 Comm: gem_madvise Tainted: G U
>> W 5.16.0-rc8-CI-CI_DRM_11046+ #1
>> <4> [749.062933] Hardware name: Gigabyte Technology Co., Ltd. GB-Z390
>> Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019
>> <4> [749.062937] RIP: 0010:i915_ttm_mmap_offset.cold.35+0x5b/0x5d
>> [i915]
>> <4> [749.063044] Code: 00 48 c7 c2 a0 23 4e a0 48 c7 c7 26 df 4a a0
>> e8 95 1d d0 e0 bf 01 00 00 00 e8 8b ec cf e0 31 f6 bf 09 00 00 00 e8
>> 5f 30 c0 e0 <0f> 0b 48 c7 c1 24 4b 56 a0 ba 5b 03 00 00 48 c7 c6 c0
>> 23 4e a0 48
>> <4> [749.063052] RSP: 0018:ffffc90002ab7d38 EFLAGS: 00010246
>> <4> [749.063056] RAX: 0000000000000240 RBX: ffff88811f2e61c0 RCX:
>> 0000000000000006
>> <4> [749.063060] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
>> 0000000000000009
>> <4> [749.063063] RBP: ffffc90002ab7e58 R08: 0000000000000001 R09:
>> 0000000000000001
>> <4> [749.063067] R10: 000000000123d0f8 R11: ffffc90002ab7b20 R12:
>> ffff888112a1a000
>> <4> [749.063071] R13: 0000000000000004 R14: ffff88811f2e61c0 R15:
>> ffff888112a1a000
>> <4> [749.063074] FS: 00007f6e5fcad500(0000)
>> GS:ffff8884ad600000(0000) knlGS:0000000000000000
>> <4> [749.063078] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> <4> [749.063081] CR2: 00007efd264e39f0 CR3: 0000000115fd6005 CR4:
>> 00000000003706f0
>> <4> [749.063085] Call Trace:
>> <4> [749.063087] <TASK>
>> <4> [749.063089] __assign_mmap_offset+0x41/0x300 [i915]
>> <4> [749.063171] __assign_mmap_offset_handle+0x159/0x270 [i915]
>> <4> [749.063248] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
>> <4> [749.063325] drm_ioctl_kernel+0xae/0x140
>> <4> [749.063330] drm_ioctl+0x201/0x3d0
>> <4> [749.063333] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
>> <4> [749.063409] ? do_user_addr_fault+0x200/0x670
>> <4> [749.063415] __x64_sys_ioctl+0x6d/0xa0
>> <4> [749.063419] do_syscall_64+0x3a/0xb0
>> <4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae
>> <4> [749.063428] RIP: 0033:0x7f6e5f100317
>>
>> Testcase: igt@gem_madvise@dontneed-before-mmap
>> Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> index 89b70f5cde7a..9f429ed6e78a 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> @@ -161,7 +161,6 @@ int i915_gem_object_pin_pages_unlocked(struct
>> drm_i915_gem_object *obj)
>> /* Immediately discard the backing storage */
>> int i915_gem_object_truncate(struct drm_i915_gem_object *obj)
>> {
>> - drm_gem_free_mmap_offset(&obj->base);
>
> What happens if a non-ttm shmem system object gets truncated from the
> shrinker and then tries to use the above mmap offset?
AFAIK nothing on integrated is really using this. The mmap_offset ioctl
stuff is managing multiple vma nodes itself, per object(one for each
cache type/mapping or something), and so doesn't use this. And the shmem
mmap ioctl doesn't use the any fake offset stuff, AFAIK.
>
> /Thomas
>
>
>
>> if (obj->ops->truncate)
>> return obj->ops->truncate(obj);
>>
>
>
^ permalink raw reply
* Re: [PATCH 19/26] x86/tdx: Make pages shared in ioremap()
From: Kirill A. Shutemov @ 2022-01-05 16:02 UTC (permalink / raw)
To: Tom Lendacky
Cc: Dave Hansen, Borislav Petkov, Kirill A. Shutemov, tglx, mingo,
luto, peterz, sathyanarayanan.kuppuswamy, aarcange, ak,
dan.j.williams, david, hpa, jgross, jmattson, joro, jpoimboe,
knsathya, pbonzini, sdeep, seanjc, tony.luck, vkuznets, wanpengli,
x86, linux-kernel
In-Reply-To: <3fd5d9b4-87ac-4f3e-bb89-60813808389b@amd.com>
On Wed, Jan 05, 2022 at 08:16:49AM -0600, Tom Lendacky wrote:
> On 1/4/22 6:43 PM, Dave Hansen wrote:
> > On 1/4/22 4:31 PM, Kirill A. Shutemov wrote:
> > > On Tue, Jan 04, 2022 at 12:36:06PM -0800, Dave Hansen wrote:
> > > > @@ -57,7 +58,6 @@ typedef struct { unsigned long iopte; }
> > > > typedef struct { unsigned long pmd; } pmd_t;
> > > > typedef struct { unsigned long pgd; } pgd_t;
> > > > typedef struct { unsigned long ctxd; } ctxd_t;
> > > > -typedef struct { unsigned long pgprot; } pgprot_t;
> > > > typedef struct { unsigned long iopgprot; } iopgprot_t;
> > > > #define pte_val(x) ((x).pte)
> > > > @@ -85,7 +85,6 @@ typedef unsigned long iopte_t;
> > > > typedef unsigned long pmd_t;
> > > > typedef unsigned long pgd_t;
> > > > typedef unsigned long ctxd_t;
> > > > -typedef unsigned long pgprot_t;
> > > > typedef unsigned long iopgprot_t;
> > > > #define pte_val(x) (x)
> > >
> > > Any arch that use STRICT_MM_TYPECHECKS hacks will get broken if compiled
> > > without the define (as sparc by default).
> >
> > My read of STRICT_MM_TYPECHECKS was that "typedef unsigned long
> > pgprot_t" produces better code, but "typedef struct { unsigned long
> > pgprot; } pgprot_t;" produces better type checking.
> >
> > I just compiled these patches on sparc with no issues.
> >
> > ...
> > > Is it the way to go we want?
> >
> > I _think_ this was all a result of some review feedback from Tom
> > Lendacky about where the encryption-modifying pgprot helpers got placed
> > in the code. I don't feel strongly about it, but I'm not quite sure
> > that this is worth the trouble.
> >
> > I'd be curious what Tom thinks now that he's gotten a peek at what it's
> > going to take to address his concerns.
>
> I have vague memories of pgprot_t and what a pain it could be, which is why
> my feedback suggested putting it in cc_platform.c, but said there might be
> issues :)
>
> I'm fine with it living somewhere else, just thought it would be nice to
> have everything consolidated, if possible.
In this case I would rather leave it in <asm/pgtable.h>. We still can
rename it to cc_pgprot_decrypted()/cc_pgprot_encrypted().
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH] Revert "net: usb: r8152: Add MAC passthrough support for more Lenovo Docks"
From: Oliver Neukum @ 2022-01-05 16:01 UTC (permalink / raw)
To: Aaron Ma, kuba, henning.schild, linux-usb, netdev, linux-kernel
Cc: davem, hayeswang, tiwai
In-Reply-To: <20220105155102.8557-1-aaron.ma@canonical.com>
On 05.01.22 16:51, Aaron Ma wrote:
> This reverts commit f77b83b5bbab53d2be339184838b19ed2c62c0a5.
>
> This change breaks multiple usb to ethernet dongles attached on Lenovo
> USB hub.
Hi,
now we should maybe discuss a sensible way to identify device
that should use passthrough. Are your reasons to not have a list
of devices maintainability or is it impossible?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 00/11] Add support for SUNIV and F1C100s.
From: Giulio Benetti @ 2022-01-05 16:00 UTC (permalink / raw)
To: Jesse Taube, Andre Przywara, Icenowy Zheng
Cc: u-boot, jagan, hdegoede, sjg, marek.behun, festevam, narmstrong,
tharvey, christianshewitt, pbrobinson, lokeshvutla,
jernej.skrabec, hs, samuel, arnaud.ferraris, thirtythreeforty
In-Reply-To: <8e85b8ea-d400-c3c1-4610-c88f5ed0510c@gmail.com>
Hi All,
On 05/01/22 13:54, Jesse Taube wrote:
>
>
> On 1/5/22 07:14, Andre Przywara wrote:
>> On Wed, 05 Jan 2022 19:36:29 +0800
>> Icenowy Zheng <icenowy@aosc.io> wrote:
>>
>> Hi Jesse,
>>
>>> 在 2022-01-04星期二的 19:34 -0500，Jesse Taube写道：
>>>> This patch set aims to add suport for the SUNIV and F1C100s.
>>>> Suport has been in linux for a while now, but not in u-boot.
>>>>
>>>> This patchset contains:
>>>> - CPU specific initialization code
>>>> - SUNIV dram driver
>>>> - SUNIV clock driver adaption
>>>> - SUNIV gpio driver adaption
>>>> - SUNIV uart driver adaption
>>>> - F1C100s basic support
>>>>
>>>> I am hoping to get Icenowy's patches in as it seems she hasnt
>>>> submitted
>>>> in a while. The only edits I made to her code is rebasing it against
>>>> ML
>>>> and changing some formating. I also re-grouped her commits.
>>>
>>> I got too lazy to send it (because I think F1C100s is just too weak)...
>>>
>>>>
>>>> I am wondering if the dram driver should be moved into device drivers
>>>> rather than in mach-sunxi.
>>>> I am also wondering if it is okay to submit some one elses code,
>>>> and if so how should I do so.
>>>
>>> As you are keeping my SoB and adding yours, it's totally okay.
>>
>> Thanks Icenowy for confirming!
>>
>> Jesse: yes, it's perfectly fine to send patches from someone else, as
>> long as you keep the authorship, their SoB, and add your's.
>> Typical reasons are lack of time or interest from the original author.
>>
>> But it's customary to ask the author first
> I did but it must have gotten lost in the cosmos.
> , and care should be taken
>> when changing patches, as this might not be in the interest of the
>> original author (and they are the ones who will get blamed for bugs).
>> Also please mark the series either as a Resend or as a v2.
>>
>> So with Icenowy's confirmation above I consider this fine.
>>
>> But what was actually holding back this series was lack of review,
>> testing and/or interest.
> Well the price of the SOC has gained it some popularity, aswell as a
> couple forum posts.
>> Similar to Icenowy my personal interest in
>> crufty old cores is somewhat limited, so this wasn't very high on my
>> priority list.
> It is very slow but its a good challenge.
Slow depending on application :-)
Two of my customers would like to use it in Q2/Q3 for very low-end HMIs.
And as I see, one of the last F1Cxxx is F1C800s released in 2017. Here
the good thing they have is ram onboard.
>>
>> So given that there is apparently some interest now:
>> Can you confirm that you have reviewed the series, or at least tested
>> this?
> I have tested this yes.
> I would be interested to know if a second pair of eyes had a
>> look, and to what extent.
> I'm Sending giulio.benetti@ some boards I made he will also test. I'm
> sure many other people will be willing to test aswell.
Yes, I'll test on Jesse's board and on Lichee-pi-nano too when I have
time, this way I'll be able to give a Tested-by: me.
Best regards
--
Giulio Benetti
Benetti Engineering sas
>> I don't have any hardware, so would need to
>> rely on others to make sure this code is somewhat sane.
> I can send you one of my many boards :)
>> And it basically looks like a v2 of Icenowy's series, so can you give a
>> Changelog of the differences? I skimmed over her original series back
>> then, so I would be interested in what makes this version special.
> It passes checkpatch on the latest.
>>
>> Cheers,
>> Andre
>>
>>> Thanks for cleaning up these patches! ;-)
> NP!
>
> I took https://github.com/Lichee-Pi/u-boot/tree/nano-v2018.01
> re-based it against mainline and fixed formatting in a few files.
> I also removed the spi-flash driver as it was causing issues and we can
> boot from sdcard for now. there are some things I did to make the old
> code compatible with new code but mostly preprocessor and configs.
>
> For the dram driver I had to change a bit but none of the logic, i am
> worried that i may have to move it to /drivers.
>
> Do you want a more comprehensive list of changes?
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.