On Thu, Mar 06, 2025 at 11:36:55AM +0100, Petr Pavlu wrote:
> In the unlikely case that setting ro_after_init data to read-only fails, it
> is too late to cancel loading of the module. The loader then issues only
> a warning about the situation. Given that this reduces the kernel's
> protection, it
: 0||
1024 -> 2047 : 10748||
Tested-by: Daniel Gomez
Andreas, Petr, Miguel,
Based on the discussion in v7, it seems that all these patches will go through
the Rust tree. Is that correct? What would be missing from t
-862b-fd77552ae...@suse.com/ [1]
> Signed-off-by: Andreas Hindborg
And this is what we signed up for here:
https://lore.kernel.org/all/zspanzx4-5dro...@bombadil.infradead.org/
Acked-by: Daniel Gomez
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/
On Mon, Jan 06, 2025 at 04:13:29PM -0800, Kees Cook wrote:
> On Fri, Jan 03, 2025 at 05:13:32PM +0100, Petr Pavlu wrote:
> > On 12/5/24 20:46, Christophe Leroy wrote:
> > > This series reworks module loading to avoid leaving the module in a
> > > stale state when protecting ro_after_init section fa
On 12/4/2024 4:14 PM, Petr Pavlu wrote:
On 11/28/24 21:23, Daniel Gomez wrote:
On 11/12/2024 3:35 PM, Petr Pavlu wrote:
On 11/12/24 10:43, Daniel Gomez wrote:
On Mon Nov 11, 2024 at 7:53 PM CET, Christophe Leroy wrote:
Le 09/11/2024 à 23:17, Daniel Gomez a écrit :
On Sat Nov 9, 2024 at 11
On 11/21/2024 9:42 PM, Sami Tolvanen wrote:
Add a basic DWARF parser, which uses libdw to traverse the debugging
information in an object file and looks for functions and variables.
In follow-up patches, this will be expanded to produce symbol versions
for CONFIG_MODVERSIONS from DWARF.
Signed-o
On 11/12/2024 3:35 PM, Petr Pavlu wrote:
On 11/12/24 10:43, Daniel Gomez wrote:
On Mon Nov 11, 2024 at 7:53 PM CET, Christophe Leroy wrote:
Le 09/11/2024 à 23:17, Daniel Gomez a écrit :
On Sat Nov 9, 2024 at 11:35 AM CET, Christophe Leroy wrote:
Once module init has succeded it is too late
On Sat Nov 16, 2024 at 6:20 PM CET, Uwe Kleine-König wrote:
> On Sat, Nov 16, 2024 at 09:15:55AM +0100, Daniel Gomez wrote:
>> On Fri Nov 15, 2024 at 7:50 PM CET, Werner Sembach wrote:
>> > From: Uwe Kleine-König
>> >
>> > TUXEDO has not yet relicensed a modu
On Fri Nov 15, 2024 at 7:50 PM CET, Werner Sembach wrote:
> From: Uwe Kleine-König
>
> TUXEDO has not yet relicensed a module for GPLv2+ as a reply from former
> contributers the committed code under GPLv3+ is awaited.
FYI, the SPDX identifier GPL-2.0+ is deprecated as of 2.0rc2 [1]. I think you'
On Thu Nov 14, 2024 at 11:31 AM CET, Uwe Kleine-König wrote:
> Tuxedo licenses the modules used on their hardware under GPLv3+, to
> "keep control of the upstream pacing" – and want to re-license the code
> while upstreaming.
>
> They were asked to then at least not use MODULE_LICENSE("GPL") which
On Thu Nov 14, 2024 at 11:31 AM CET, Uwe Kleine-König wrote:
> Hello,
>
> the kernel modules provided by Tuxedo on
> https://protect2.fireeye.com/v1/url?k=2f239e82-70bfb7a8-2f2215cd-000babe598f7-32952349600b722d&q=1&e=9535a8fa-5a9d-4d94-a12d-ff39b9d3b9cf&u=https%3A%2F%2Fgitlab.com%2Ftuxedocomputers
On Mon Nov 11, 2024 at 7:53 PM CET, Christophe Leroy wrote:
>
>
> Le 09/11/2024 à 23:17, Daniel Gomez a écrit :
>> On Sat Nov 9, 2024 at 11:35 AM CET, Christophe Leroy wrote:
>>> Once module init has succeded it is too late to cancel loading.
>>> If setting ro_aft
t section needs to be
> set to read-only, no need to re-apply it to already set rodata.
>
> Split module_enable_rodata_ro() in two.
>
> Signed-off-by: Christophe Leroy
Tested-by: Daniel Gomez
> ---
> kernel/module/internal.h | 3 ++-
> kernel/module/main.c | 4
On Sat Nov 9, 2024 at 11:35 AM CET, Christophe Leroy wrote:
> Once module init has succeded it is too late to cancel loading.
> If setting ro_after_init data section to read-only fails, all we
> can do is to inform the user through a warning.
>
> Reported-by: Thomas Gleixner
> Closes:
> https://l
On Sat Nov 9, 2024 at 11:35 AM CET, Christophe Leroy wrote:
> To be on the safe side, try to set ro_after_init data section readonly
> at the same time as rodata. If it fails it will likely fail again
> later so let's cancel module loading while we still can do it.
> If it doesn't fail, put it back
On Fri Nov 8, 2024 at 5:09 PM CET, Daniel Gomez wrote:
> On Fri Nov 8, 2024 at 4:49 PM CET, Luis Chamberlain wrote:
>> + Other new module maintainers
>>
>> On Fri, Nov 08, 2024 at 09:12:03AM +0100, Christophe Leroy wrote:
>>> Hi Luis,
>>>
>>&
From: Daniel Gomez
When ro_after_init fails, we need to unload the module.
Rename the goto tag to fail_ro_after_init to make it more clear and try
to check for dependencies, stop the module and call the exit function.
This allows to unload the module if ro_after_init fails.
This fixes the
From: Daniel Gomez
Ensure the module state change and reference drop operations are
performed within module_mutex to prevent potential race conditions in
the failure path.
Signed-off-by: Daniel Gomez
---
kernel/module/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Daniel Gomez
Ensure the module reference is only dropped once in case we fail at
MOD_RO_AFTER_INIT case.
Signed-off-by: Daniel Gomez
---
kernel/module/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index
pping(bdev);
>679< if (bdev->bd_disk->fops->release)
680bdev->bd_disk->fops->release(bdev->bd_disk);
681}
682
683static int blkdev_get_whole(struct block_device *bdev, blk_mode_t mode)
684{
To: Luis Chamberlain
To: Petr
From: Daniel Gomez
The module_deallocate() function no longer requires the struct load_info
parameter as of commit 48fd11880b5ef04270be8a87d9a9a9ee2fdae338 ("module:
Fix performance regression on modules with large symbol tables"). This
commit removes the now-unused parameter.
No
ode
> to address this seems complex. right ?
I have a RFC ready with this, I'll send this now so we can discuss on
with a proposal.
>
>
>> Especially when the module has no exit() path or when
>> CONFIG_MODULE_UNLOAD is not built in.
>
> That's exactly the othe
On 9/24/2024 11:19 PM, Matthew Maurer wrote:
`validate_section_offset` doesn't modify the info passed in. Make this
clear by adjusting the type signature.
Signed-off-by: Matthew Maurer
---
kernel/module/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/module/
Rust and C code for modules so we can ensure we get proper
> reviews for both parts of the code and so that we can scale.
>
> Add those who have stepped up to help.
>
> Signed-off-by: Luis Chamberlain
> ---
Acked-by: Daniel Gomez
Daniel
>
> First order of busine
On Wed, Jul 24, 2024 at 05:04:25PM GMT, Sami Tolvanen wrote:
> Hi Luis,
>
> On Thu, Jul 18, 2024 at 5:15 PM Luis Chamberlain wrote:
> >
> > On Tue, Jul 09, 2024 at 12:08:16PM +0200, Miguel Ojeda wrote:
> > > On Mon, Jul 8, 2024 at 11:42 PM Luis Chamberlain
> > > wrote:
> > > >
> > > > The ratio
On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote:
>
> On Mon, Mar 22, 2021 at 6:34 AM Christian König
> wrote:
> >
> > Hi Daniel,
> >
> > Am 22.03.21 um 10:38 schrieb Daniel Gomez:
> > > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling
> > > wro
On Fri, 26 Mar 2021 at 13:28, Andy Shevchenko
wrote:
>
> On Fri, Mar 26, 2021 at 11:35:08AM +0100, Daniel Gomez wrote:
> > On Thu, 25 Mar 2021 at 16:43, Andy Shevchenko
> > wrote:
> > > On Thu, Mar 25, 2021 at 04:12:48PM +0100, Daniel Gomez wrote:
>
> ...
>
&g
Hi Andy,
On Thu, 25 Mar 2021 at 16:43, Andy Shevchenko
wrote:
>
> On Thu, Mar 25, 2021 at 04:12:48PM +0100, Daniel Gomez wrote:
> > Add i2c hw base address in the adapter name and when the device is
> > probed.
>
> Why?
> We have /proc/iomem for that.
The initial
root@qt5222:~# i2cdetect -l | grep -i desig
i2c-1 i2c Synopsys DesignWare I2C adapter at 0xfedc5000
I2C adapter
i2c-0 i2c Synopsys DesignWare I2C adapter at 0xfedc4000
I2C adapter
Signed-off-by: Daniel Gomez
---
Hi,
We think it might be interesting to add the physical
On Mon, 22 Mar 2021 at 11:34, Christian König
wrote:
>
> Hi Daniel,
>
> Am 22.03.21 um 10:38 schrieb Daniel Gomez:
> > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling wrote:
> >> This caused a regression in kfdtest in a large-buffer stress test after
> >> me
gt;sg_table) {
if (gtt->user_ptr) ...
}
If you agree, I'll send a v2 patch. Otherwise, maybe we could return
within amdgpu_ttm_tt_unpin_userptr if memory hasn't been allocated.
Any other ideas?
Regards,
Daniel
>
> Reverting this patch fixes the problem for me.
>
&g
If userptr pages have been pinned but not bounded,
they remain uncleared.
Signed-off-by: Daniel Gomez
---
drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index
On Thu, 18 Mar 2021 at 08:49, Christian König wrote:
>
> Am 17.03.21 um 17:08 schrieb Daniel Gomez:
> > If userptr pages have been pinned but not bounded,
> > they remain uncleared.
> >
> > Signed-off-by: Daniel Gomez
>
> Good catch, not sure if that can eve
If userptr pages have been pinned but not bounded,
they remain uncleared.
Signed-off-by: Daniel Gomez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu
On Thu, 11 Mar 2021 at 17:10, Alex Deucher wrote:
>
> On Thu, Mar 11, 2021 at 10:02 AM Alexandre Desnoyers wrote:
> >
> > On Thu, Mar 11, 2021 at 2:49 PM Daniel Gomez wrote:
> > >
> > > On Thu, 11 Mar 2021 at 10:09, Daniel Gomez wrote:
> > > >
&g
On Thu, 11 Mar 2021 at 10:09, Daniel Gomez wrote:
>
> On Wed, 10 Mar 2021 at 18:06, Alex Deucher wrote:
> >
> > On Wed, Mar 10, 2021 at 11:37 AM Daniel Gomez wrote:
> > >
> > > Disabling GFXOFF via the quirk list fixes a hardware lockup in
> > &g
On Wed, 10 Mar 2021 at 18:06, Alex Deucher wrote:
>
> On Wed, Mar 10, 2021 at 11:37 AM Daniel Gomez wrote:
> >
> > Disabling GFXOFF via the quirk list fixes a hardware lockup in
> > Ryzen V1605B, RAVEN 0x1002:0x15DD rev 0x83.
> >
> > Signed-off-by: Daniel Go
Disabling GFXOFF via the quirk list fixes a hardware lockup in
Ryzen V1605B, RAVEN 0x1002:0x15DD rev 0x83.
Signed-off-by: Daniel Gomez
---
This patch is a continuation of the work here:
https://lkml.org/lkml/2021/2/3/122 where a hardware lockup was discussed and
a dma_fence deadlock was provoke
n though it is not used in that stack.
Anyway, I'll keep you guys posted with this change.
>
> Regards,
> Christian.
>
> Am 03.02.21 um 09:33 schrieb Daniel Gomez:
> > Hi all,
> >
> > I have a deadlock with the amdgpu mainline driver when running in paralle
On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
>
> On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 9:51 AM Christian König
> > wrote:
> > >
> > > Am 03.02.21 um 09:48 schrieb Daniel Vetter:
> > &g
t; Yeah, that's still a good idea to have.
Here the full backtrace dmesg logs after the hang:
https://pastebin.com/raw/kzivm2L3
This is another dmesg log with the backtraces after SIGKILL the matrix process:
(I didn't have the sysrq enable at the time):
https://pastebin.com/raw/pRBwGcj1
the 'latest' linux-firmware adds support for the
20.45 version but
I haven't tested it yet since I couldn't bring it up properly the
support as I was doing for
the previous versions. Somehow the libamdocl64.so got reduced from 80 Mb to
1.2 Mb and I couldn't figure out
Hi all,
I have a deadlock with the amdgpu mainline driver when running in parallel two
OpenCL applications. So far, we've been able to replicate it easily by executing
clinfo and MatrixMultiplication (from AMD opencl-samples). It's quite old the
opencl-samples so, if you have any other suggestion
0xe10): undefined reference to
`drm_atomic_helper_connector_destroy_state'
Signed-off-by: Daniel Gomez
---
drivers/gpu/drm/rcar-du/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 0919f1f159a4..f65d1489dc50 100644
--- a/drivers/gpu/drm/rcar-du
Hi all,
We are developing a v4l2 subdevice driver to be able to support the imx378
sensor and upstream it. But we would like to have a continuous frame
interval and the
current VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL ioctl implementation doesn't
support it.
How can we proceed here? Can we maybe add the
Stop video streaming when requested.
When s_stream is called to stop the video streaming, if/else condition calls
start_streaming function instead of the one for stopping it.
Fixes: 436190596241 ("media: imx214: Add imx214 camera sensor driver")
Signed-off-by: Daniel Gomez
---
Yo
: of:N*T*Ccirrus,cs47l35
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/mfd/madera-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
index 2a77988..826b971 100644
--- a/drivers/mfd/madera-core.c
+++ b
Signed-off-by: Daniel Gomez
---
drivers/iio/temperature/maxim_thermocouple.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/iio/temperature/maxim_thermocouple.c
b/drivers/iio/temperature/maxim_thermocouple.c
index c31b963..c613a64 100644
--- a/drivers/iio/temperature
alias: of:N*T*Cadi,ad5758C*
alias: of:N*T*Cadi,ad5758
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/iio/dac/ad5758.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iio/dac/ad5758.c b/drivers/iio/dac/ad5758.c
index 2bdf1b0
: of:N*T*Cadi,adxl372C*
alias: of:N*T*Cadi,adxl372
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/iio/accel/adxl372_spi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iio/accel/adxl372_spi.c b/drivers/iio/accel/adxl372_spi.c
index
: spi:kxsd9
alias: of:N*T*Ckionix,kxsd9C*
alias: of:N*T*Ckionix,kxsd9
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/iio/accel/kxsd9-spi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iio/accel/kxsd9-spi.c b/drivers/iio/accel
*
alias: of:N*T*Cti,tps65912
alias: spi:tps65912
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/mfd/tps65912-spi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/tps65912-spi.c b/drivers/mfd/tps65912-spi.c
index 3bd7506..f78be03
52 matches
Mail list logo
