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
49 matches
Mail list logo
