<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/lib/test_firmware.c, branch v5.4.285</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>test_firmware: return ENOMEM instead of ENOSPC on failed memory allocation</title>
<updated>2023-08-11T09:54:00+00:00</updated>
<author>
<name>Mirsad Goran Todorovac</name>
<email>mirsad.todorovac@alu.unizg.hr</email>
</author>
<published>2023-06-06T07:08:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2af8ed119722a6f3abc728b37efe3ff12e988517'/>
<id>2af8ed119722a6f3abc728b37efe3ff12e988517</id>
<content type='text'>
commit 7dae593cd226a0bca61201cf85ceb9335cf63682 upstream.

In a couple of situations like

	name = kstrndup(buf, count, GFP_KERNEL);
	if (!name)
		return -ENOSPC;

the error is not actually "No space left on device", but "Out of memory".

It is semantically correct to return -ENOMEM in all failed kstrndup()
and kzalloc() cases in this driver, as it is not a problem with disk
space, but with kernel memory allocator failing allocation.

The semantically correct should be:

        name = kstrndup(buf, count, GFP_KERNEL);
        if (!name)
                return -ENOMEM;

Cc: Dan Carpenter &lt;error27@gmail.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: "Luis R. Rodriguez" &lt;mcgrof@ruslug.rutgers.edu&gt;
Cc: Scott Branden &lt;sbranden@broadcom.com&gt;
Cc: Hans de Goede &lt;hdegoede@redhat.com&gt;
Cc: Brian Norris &lt;briannorris@chromium.org&gt;
Fixes: c92316bf8e948 ("test_firmware: add batched firmware tests")
Fixes: 0a8adf584759c ("test: add firmware_class loader test")
Fixes: 548193cba2a7d ("test_firmware: add support for firmware_request_platform")
Fixes: eb910947c82f9 ("test: firmware_class: add asynchronous request trigger")
Fixes: 061132d2b9c95 ("test_firmware: add test custom fallback trigger")
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Message-ID: &lt;20230606070808.9300-1-mirsad.todorovac@alu.unizg.hr&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7dae593cd226a0bca61201cf85ceb9335cf63682 upstream.

In a couple of situations like

	name = kstrndup(buf, count, GFP_KERNEL);
	if (!name)
		return -ENOSPC;

the error is not actually "No space left on device", but "Out of memory".

It is semantically correct to return -ENOMEM in all failed kstrndup()
and kzalloc() cases in this driver, as it is not a problem with disk
space, but with kernel memory allocator failing allocation.

The semantically correct should be:

        name = kstrndup(buf, count, GFP_KERNEL);
        if (!name)
                return -ENOMEM;

Cc: Dan Carpenter &lt;error27@gmail.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: "Luis R. Rodriguez" &lt;mcgrof@ruslug.rutgers.edu&gt;
Cc: Scott Branden &lt;sbranden@broadcom.com&gt;
Cc: Hans de Goede &lt;hdegoede@redhat.com&gt;
Cc: Brian Norris &lt;briannorris@chromium.org&gt;
Fixes: c92316bf8e948 ("test_firmware: add batched firmware tests")
Fixes: 0a8adf584759c ("test: add firmware_class loader test")
Fixes: 548193cba2a7d ("test_firmware: add support for firmware_request_platform")
Fixes: eb910947c82f9 ("test: firmware_class: add asynchronous request trigger")
Fixes: 061132d2b9c95 ("test_firmware: add test custom fallback trigger")
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Message-ID: &lt;20230606070808.9300-1-mirsad.todorovac@alu.unizg.hr&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test_firmware: prevent race conditions by a correct implementation of locking</title>
<updated>2023-08-11T09:53:59+00:00</updated>
<author>
<name>Mirsad Goran Todorovac</name>
<email>mirsad.todorovac@alu.unizg.hr</email>
</author>
<published>2023-05-09T08:47:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0f68b0f8eb5ae147d316ac673837da4c42dfe1fe'/>
<id>0f68b0f8eb5ae147d316ac673837da4c42dfe1fe</id>
<content type='text'>
commit 4acfe3dfde685a5a9eaec5555351918e2d7266a1 upstream.

Dan Carpenter spotted a race condition in a couple of situations like
these in the test_firmware driver:

static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
        u8 val;
        int ret;

        ret = kstrtou8(buf, 10, &amp;val);
        if (ret)
                return ret;

        mutex_lock(&amp;test_fw_mutex);
        *(u8 *)cfg = val;
        mutex_unlock(&amp;test_fw_mutex);

        /* Always return full write size even if we didn't consume all */
        return size;
}

static ssize_t config_num_requests_store(struct device *dev,
                                         struct device_attribute *attr,
                                         const char *buf, size_t count)
{
        int rc;

        mutex_lock(&amp;test_fw_mutex);
        if (test_fw_config-&gt;reqs) {
                pr_err("Must call release_all_firmware prior to changing config\n");
                rc = -EINVAL;
                mutex_unlock(&amp;test_fw_mutex);
                goto out;
        }
        mutex_unlock(&amp;test_fw_mutex);

        rc = test_dev_config_update_u8(buf, count,
                                       &amp;test_fw_config-&gt;num_requests);

out:
        return rc;
}

static ssize_t config_read_fw_idx_store(struct device *dev,
                                        struct device_attribute *attr,
                                        const char *buf, size_t count)
{
        return test_dev_config_update_u8(buf, count,
                                         &amp;test_fw_config-&gt;read_fw_idx);
}

The function test_dev_config_update_u8() is called from both the locked
and the unlocked context, function config_num_requests_store() and
config_read_fw_idx_store() which can both be called asynchronously as
they are driver's methods, while test_dev_config_update_u8() and siblings
change their argument pointed to by u8 *cfg or similar pointer.

To avoid deadlock on test_fw_mutex, the lock is dropped before calling
test_dev_config_update_u8() and re-acquired within test_dev_config_update_u8()
itself, but alas this creates a race condition.

Having two locks wouldn't assure a race-proof mutual exclusion.

This situation is best avoided by the introduction of a new, unlocked
function __test_dev_config_update_u8() which can be called from the locked
context and reducing test_dev_config_update_u8() to:

static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
        int ret;

        mutex_lock(&amp;test_fw_mutex);
        ret = __test_dev_config_update_u8(buf, size, cfg);
        mutex_unlock(&amp;test_fw_mutex);

        return ret;
}

doing the locking and calling the unlocked primitive, which enables both
locked and unlocked versions without duplication of code.

The similar approach was applied to all functions called from the locked
and the unlocked context, which safely mitigates both deadlocks and race
conditions in the driver.

__test_dev_config_update_bool(), __test_dev_config_update_u8() and
__test_dev_config_update_size_t() unlocked versions of the functions
were introduced to be called from the locked contexts as a workaround
without releasing the main driver's lock and thereof causing a race
condition.

The test_dev_config_update_bool(), test_dev_config_update_u8() and
test_dev_config_update_size_t() locked versions of the functions
are being called from driver methods without the unnecessary multiplying
of the locking and unlocking code for each method, and complicating
the code with saving of the return value across lock.

Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Russ Weight &lt;russell.h.weight@intel.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Tianfei Zhang &lt;tianfei.zhang@intel.com&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Cc: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Suggested-by: Dan Carpenter &lt;error27@gmail.com&gt;
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Link: https://lore.kernel.org/r/20230509084746.48259-1-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4acfe3dfde685a5a9eaec5555351918e2d7266a1 upstream.

Dan Carpenter spotted a race condition in a couple of situations like
these in the test_firmware driver:

static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
        u8 val;
        int ret;

        ret = kstrtou8(buf, 10, &amp;val);
        if (ret)
                return ret;

        mutex_lock(&amp;test_fw_mutex);
        *(u8 *)cfg = val;
        mutex_unlock(&amp;test_fw_mutex);

        /* Always return full write size even if we didn't consume all */
        return size;
}

static ssize_t config_num_requests_store(struct device *dev,
                                         struct device_attribute *attr,
                                         const char *buf, size_t count)
{
        int rc;

        mutex_lock(&amp;test_fw_mutex);
        if (test_fw_config-&gt;reqs) {
                pr_err("Must call release_all_firmware prior to changing config\n");
                rc = -EINVAL;
                mutex_unlock(&amp;test_fw_mutex);
                goto out;
        }
        mutex_unlock(&amp;test_fw_mutex);

        rc = test_dev_config_update_u8(buf, count,
                                       &amp;test_fw_config-&gt;num_requests);

out:
        return rc;
}

static ssize_t config_read_fw_idx_store(struct device *dev,
                                        struct device_attribute *attr,
                                        const char *buf, size_t count)
{
        return test_dev_config_update_u8(buf, count,
                                         &amp;test_fw_config-&gt;read_fw_idx);
}

The function test_dev_config_update_u8() is called from both the locked
and the unlocked context, function config_num_requests_store() and
config_read_fw_idx_store() which can both be called asynchronously as
they are driver's methods, while test_dev_config_update_u8() and siblings
change their argument pointed to by u8 *cfg or similar pointer.

To avoid deadlock on test_fw_mutex, the lock is dropped before calling
test_dev_config_update_u8() and re-acquired within test_dev_config_update_u8()
itself, but alas this creates a race condition.

Having two locks wouldn't assure a race-proof mutual exclusion.

This situation is best avoided by the introduction of a new, unlocked
function __test_dev_config_update_u8() which can be called from the locked
context and reducing test_dev_config_update_u8() to:

static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
        int ret;

        mutex_lock(&amp;test_fw_mutex);
        ret = __test_dev_config_update_u8(buf, size, cfg);
        mutex_unlock(&amp;test_fw_mutex);

        return ret;
}

doing the locking and calling the unlocked primitive, which enables both
locked and unlocked versions without duplication of code.

The similar approach was applied to all functions called from the locked
and the unlocked context, which safely mitigates both deadlocks and race
conditions in the driver.

__test_dev_config_update_bool(), __test_dev_config_update_u8() and
__test_dev_config_update_size_t() unlocked versions of the functions
were introduced to be called from the locked contexts as a workaround
without releasing the main driver's lock and thereof causing a race
condition.

The test_dev_config_update_bool(), test_dev_config_update_u8() and
test_dev_config_update_size_t() locked versions of the functions
are being called from driver methods without the unnecessary multiplying
of the locking and unlocking code for each method, and complicating
the code with saving of the return value across lock.

Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Russ Weight &lt;russell.h.weight@intel.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Tianfei Zhang &lt;tianfei.zhang@intel.com&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Cc: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Suggested-by: Dan Carpenter &lt;error27@gmail.com&gt;
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Link: https://lore.kernel.org/r/20230509084746.48259-1-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test_firmware: fix a memory leak with reqs buffer</title>
<updated>2023-06-21T13:44:08+00:00</updated>
<author>
<name>Mirsad Goran Todorovac</name>
<email>mirsad.todorovac@alu.unizg.hr</email>
</author>
<published>2023-05-09T08:47:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=75d9e00f65cd2e0f2ce9ceeb395f821976773489'/>
<id>75d9e00f65cd2e0f2ce9ceeb395f821976773489</id>
<content type='text'>
[ Upstream commit be37bed754ed90b2655382f93f9724b3c1aae847 ]

Dan Carpenter spotted that test_fw_config-&gt;reqs will be leaked if
trigger_batched_requests_store() is called two or more times.
The same appears with trigger_batched_requests_async_store().

This bug wasn't trigger by the tests, but observed by Dan's visual
inspection of the code.

The recommended workaround was to return -EBUSY if test_fw_config-&gt;reqs
is already allocated.

Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Russ Weight &lt;russell.h.weight@intel.com&gt;
Cc: Tianfei Zhang &lt;tianfei.zhang@intel.com&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Cc: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Suggested-by: Dan Carpenter &lt;error27@gmail.com&gt;
Suggested-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Link: https://lore.kernel.org/r/20230509084746.48259-2-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit be37bed754ed90b2655382f93f9724b3c1aae847 ]

Dan Carpenter spotted that test_fw_config-&gt;reqs will be leaked if
trigger_batched_requests_store() is called two or more times.
The same appears with trigger_batched_requests_async_store().

This bug wasn't trigger by the tests, but observed by Dan's visual
inspection of the code.

The recommended workaround was to return -EBUSY if test_fw_config-&gt;reqs
is already allocated.

Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Russ Weight &lt;russell.h.weight@intel.com&gt;
Cc: Tianfei Zhang &lt;tianfei.zhang@intel.com&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Cc: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Suggested-by: Dan Carpenter &lt;error27@gmail.com&gt;
Suggested-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Link: https://lore.kernel.org/r/20230509084746.48259-2-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test_firmware: fix the memory leak of the allocated firmware buffer</title>
<updated>2023-06-09T08:29:03+00:00</updated>
<author>
<name>Mirsad Goran Todorovac</name>
<email>mirsad.todorovac@alu.unizg.hr</email>
</author>
<published>2023-05-09T08:47:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=94f3bc7e84af2f17dbfbc7afe93991c2a6f2f25e'/>
<id>94f3bc7e84af2f17dbfbc7afe93991c2a6f2f25e</id>
<content type='text'>
commit 48e156023059e57a8fc68b498439832f7600ffff upstream.

The following kernel memory leak was noticed after running
tools/testing/selftests/firmware/fw_run_tests.sh:

[root@pc-mtodorov firmware]# cat /sys/kernel/debug/kmemleak
.
.
.
unreferenced object 0xffff955389bc3400 (size 1024):
  comm "test_firmware-0", pid 5451, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334b400 (size 1024):
  comm "test_firmware-1", pid 5452, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334f000 (size 1024):
  comm "test_firmware-2", pid 5453, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c3348400 (size 1024):
  comm "test_firmware-3", pid 5454, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
[root@pc-mtodorov firmware]#

Note that the size 1024 corresponds to the size of the test firmware
buffer. The actual number of the buffers leaked is around 70-110,
depending on the test run.

The cause of the leak is the following:

request_partial_firmware_into_buf() and request_firmware_into_buf()
provided firmware buffer isn't released on release_firmware(), we
have allocated it and we are responsible for deallocating it manually.
This is introduced in a number of context where previously only
release_firmware() was called, which was insufficient.

Reported-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Dan Carpenter &lt;error27@gmail.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Cc: Russ Weight &lt;russell.h.weight@intel.com&gt;
Cc: Tianfei zhang &lt;tianfei.zhang@intel.com&gt;
Cc: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Cc: Zhengchao Shao &lt;shaozhengchao@huawei.com&gt;
Cc: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Cc: linux-kernel@vger.kernel.org
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Scott Branden &lt;sbranden@broadcom.com&gt;
Cc: Luis R. Rodriguez &lt;mcgrof@kernel.org&gt;
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Link: https://lore.kernel.org/r/20230509084746.48259-3-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 48e156023059e57a8fc68b498439832f7600ffff upstream.

The following kernel memory leak was noticed after running
tools/testing/selftests/firmware/fw_run_tests.sh:

[root@pc-mtodorov firmware]# cat /sys/kernel/debug/kmemleak
.
.
.
unreferenced object 0xffff955389bc3400 (size 1024):
  comm "test_firmware-0", pid 5451, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334b400 (size 1024):
  comm "test_firmware-1", pid 5452, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334f000 (size 1024):
  comm "test_firmware-2", pid 5453, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c3348400 (size 1024):
  comm "test_firmware-3", pid 5454, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
[root@pc-mtodorov firmware]#

Note that the size 1024 corresponds to the size of the test firmware
buffer. The actual number of the buffers leaked is around 70-110,
depending on the test run.

The cause of the leak is the following:

request_partial_firmware_into_buf() and request_firmware_into_buf()
provided firmware buffer isn't released on release_firmware(), we
have allocated it and we are responsible for deallocating it manually.
This is introduced in a number of context where previously only
release_firmware() was called, which was insufficient.

Reported-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Dan Carpenter &lt;error27@gmail.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Cc: Russ Weight &lt;russell.h.weight@intel.com&gt;
Cc: Tianfei zhang &lt;tianfei.zhang@intel.com&gt;
Cc: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Cc: Zhengchao Shao &lt;shaozhengchao@huawei.com&gt;
Cc: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Cc: linux-kernel@vger.kernel.org
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Scott Branden &lt;sbranden@broadcom.com&gt;
Cc: Luis R. Rodriguez &lt;mcgrof@kernel.org&gt;
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Link: https://lore.kernel.org/r/20230509084746.48259-3-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test_firmware: fix memory leak in test_firmware_init()</title>
<updated>2023-01-18T10:41:23+00:00</updated>
<author>
<name>Zhengchao Shao</name>
<email>shaozhengchao@huawei.com</email>
</author>
<published>2022-11-19T03:57:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=628de998a3abfffb3f9677d2fb39a1d5dcb32fdb'/>
<id>628de998a3abfffb3f9677d2fb39a1d5dcb32fdb</id>
<content type='text'>
[ Upstream commit 7610615e8cdb3f6f5bbd9d8e7a5d8a63e3cabf2e ]

When misc_register() failed in test_firmware_init(), the memory pointed
by test_fw_config-&gt;name is not released. The memory leak information is
as follows:
unreferenced object 0xffff88810a34cb00 (size 32):
  comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s)
  hex dump (first 32 bytes):
    74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69  test-firmware.bi
    6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  n...............
  backtrace:
    [&lt;ffffffff81b21fcb&gt;] __kmalloc_node_track_caller+0x4b/0xc0
    [&lt;ffffffff81affb96&gt;] kstrndup+0x46/0xc0
    [&lt;ffffffffa0403a49&gt;] __test_firmware_config_init+0x29/0x380 [test_firmware]
    [&lt;ffffffffa040f068&gt;] 0xffffffffa040f068
    [&lt;ffffffff81002c41&gt;] do_one_initcall+0x141/0x780
    [&lt;ffffffff816a72c3&gt;] do_init_module+0x1c3/0x630
    [&lt;ffffffff816adb9e&gt;] load_module+0x623e/0x76a0
    [&lt;ffffffff816af471&gt;] __do_sys_finit_module+0x181/0x240
    [&lt;ffffffff89978f99&gt;] do_syscall_64+0x39/0xb0
    [&lt;ffffffff89a0008b&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests")
Signed-off-by: Zhengchao Shao &lt;shaozhengchao@huawei.com&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Link: https://lore.kernel.org/r/20221119035721.18268-1-shaozhengchao@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7610615e8cdb3f6f5bbd9d8e7a5d8a63e3cabf2e ]

When misc_register() failed in test_firmware_init(), the memory pointed
by test_fw_config-&gt;name is not released. The memory leak information is
as follows:
unreferenced object 0xffff88810a34cb00 (size 32):
  comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s)
  hex dump (first 32 bytes):
    74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69  test-firmware.bi
    6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  n...............
  backtrace:
    [&lt;ffffffff81b21fcb&gt;] __kmalloc_node_track_caller+0x4b/0xc0
    [&lt;ffffffff81affb96&gt;] kstrndup+0x46/0xc0
    [&lt;ffffffffa0403a49&gt;] __test_firmware_config_init+0x29/0x380 [test_firmware]
    [&lt;ffffffffa040f068&gt;] 0xffffffffa040f068
    [&lt;ffffffff81002c41&gt;] do_one_initcall+0x141/0x780
    [&lt;ffffffff816a72c3&gt;] do_init_module+0x1c3/0x630
    [&lt;ffffffff816adb9e&gt;] load_module+0x623e/0x76a0
    [&lt;ffffffff816af471&gt;] __do_sys_finit_module+0x181/0x240
    [&lt;ffffffff89978f99&gt;] do_syscall_64+0x39/0xb0
    [&lt;ffffffff89a0008b&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests")
Signed-off-by: Zhengchao Shao &lt;shaozhengchao@huawei.com&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Link: https://lore.kernel.org/r/20221119035721.18268-1-shaozhengchao@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test_firmware: add support for request_firmware_into_buf</title>
<updated>2019-09-04T11:31:28+00:00</updated>
<author>
<name>Scott Branden</name>
<email>scott.branden@broadcom.com</email>
</author>
<published>2019-08-22T18:40:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7feebfa487b929b3e085f4f11ae7ac9e2e92e848'/>
<id>7feebfa487b929b3e085f4f11ae7ac9e2e92e848</id>
<content type='text'>
Add test config into_buf to allow request_firmware_into_buf to be
called instead of request_firmware/request_firmware_direct.  The number
of parameters differ calling request_firmware_into_buf and support
has not been added to test such api in test_firmware until now.

Signed-off-by: Scott Branden &lt;scott.branden@broadcom.com&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Acked-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Link: https://lore.kernel.org/r/20190822184005.901-2-scott.branden@broadcom.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add test config into_buf to allow request_firmware_into_buf to be
called instead of request_firmware/request_firmware_direct.  The number
of parameters differ calling request_firmware_into_buf and support
has not been added to test such api in test_firmware until now.

Signed-off-by: Scott Branden &lt;scott.branden@broadcom.com&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Acked-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Link: https://lore.kernel.org/r/20190822184005.901-2-scott.branden@broadcom.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test_firmware: fix a memory leak bug</title>
<updated>2019-07-25T12:39:52+00:00</updated>
<author>
<name>Wenwen Wang</name>
<email>wenwen@cs.uga.edu</email>
</author>
<published>2019-07-14T06:11:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d4fddac5a51c378c5d3e68658816c37132611e1f'/>
<id>d4fddac5a51c378c5d3e68658816c37132611e1f</id>
<content type='text'>
In test_firmware_init(), the buffer pointed to by the global pointer
'test_fw_config' is allocated through kzalloc(). Then, the buffer is
initialized in __test_firmware_config_init(). In the case that the
initialization fails, the following execution in test_firmware_init() needs
to be terminated with an error code returned to indicate this failure.
However, the allocated buffer is not freed on this execution path, leading
to a memory leak bug.

To fix the above issue, free the allocated buffer before returning from
test_firmware_init().

Signed-off-by: Wenwen Wang &lt;wenwen@cs.uga.edu&gt;
Link: https://lore.kernel.org/r/1563084696-6865-1-git-send-email-wang6495@umn.edu
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In test_firmware_init(), the buffer pointed to by the global pointer
'test_fw_config' is allocated through kzalloc(). Then, the buffer is
initialized in __test_firmware_config_init(). In the case that the
initialization fails, the following execution in test_firmware_init() needs
to be terminated with an error code returned to indicate this failure.
However, the allocated buffer is not freed on this execution path, leading
to a memory leak bug.

To fix the above issue, free the allocated buffer before returning from
test_firmware_init().

Signed-off-by: Wenwen Wang &lt;wenwen@cs.uga.edu&gt;
Link: https://lore.kernel.org/r/1563084696-6865-1-git-send-email-wang6495@umn.edu
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'char-misc-5.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc</title>
<updated>2019-06-08T19:50:36+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-06-08T19:50:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1ce2c85137b1db5b0e4158d558cb93dcff7674df'/>
<id>1ce2c85137b1db5b0e4158d558cb93dcff7674df</id>
<content type='text'>
Pull char/misc driver fixes from Greg KH:
 "Here are some small char and misc driver fixes for 5.2-rc4 to resolve
  a number of reported issues.

  The most "notable" one here is the kernel headers in proc^Wsysfs
  fixes. Those changes move the header file info into sysfs and fixes
  the build issues that you reported.

  Other than that, a bunch of small habanalabs driver fixes, some fpga
  driver fixes, and a few other tiny driver fixes.

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'char-misc-5.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  habanalabs: Read upper bits of trace buffer from RWPHI
  habanalabs: Fix virtual address access via debugfs for 2MB pages
  fpga: zynqmp-fpga: Correctly handle error pointer
  habanalabs: fix bug in checking huge page optimization
  habanalabs: Avoid using a non-initialized MMU cache mutex
  habanalabs: fix debugfs code
  uapi/habanalabs: add opcode for enable/disable device debug mode
  habanalabs: halt debug engines on user process close
  test_firmware: Use correct snprintf() limit
  genwqe: Prevent an integer overflow in the ioctl
  parport: Fix mem leak in parport_register_dev_model
  fpga: dfl: expand minor range when registering chrdev region
  fpga: dfl: Add lockdep classes for pdata-&gt;lock
  fpga: dfl: afu: Pass the correct device to dma_mapping_error()
  fpga: stratix10-soc: fix use-after-free on s10_init()
  w1: ds2408: Fix typo after 49695ac46861 (reset on output_write retry with readback)
  kheaders: Do not regenerate archive if config is not changed
  kheaders: Move from proc to sysfs
  lkdtm/bugs: Adjust recursion test to avoid elision
  lkdtm/usercopy: Moves the KERNEL_DS test to non-canonical
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull char/misc driver fixes from Greg KH:
 "Here are some small char and misc driver fixes for 5.2-rc4 to resolve
  a number of reported issues.

  The most "notable" one here is the kernel headers in proc^Wsysfs
  fixes. Those changes move the header file info into sysfs and fixes
  the build issues that you reported.

  Other than that, a bunch of small habanalabs driver fixes, some fpga
  driver fixes, and a few other tiny driver fixes.

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'char-misc-5.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  habanalabs: Read upper bits of trace buffer from RWPHI
  habanalabs: Fix virtual address access via debugfs for 2MB pages
  fpga: zynqmp-fpga: Correctly handle error pointer
  habanalabs: fix bug in checking huge page optimization
  habanalabs: Avoid using a non-initialized MMU cache mutex
  habanalabs: fix debugfs code
  uapi/habanalabs: add opcode for enable/disable device debug mode
  habanalabs: halt debug engines on user process close
  test_firmware: Use correct snprintf() limit
  genwqe: Prevent an integer overflow in the ioctl
  parport: Fix mem leak in parport_register_dev_model
  fpga: dfl: expand minor range when registering chrdev region
  fpga: dfl: Add lockdep classes for pdata-&gt;lock
  fpga: dfl: afu: Pass the correct device to dma_mapping_error()
  fpga: stratix10-soc: fix use-after-free on s10_init()
  w1: ds2408: Fix typo after 49695ac46861 (reset on output_write retry with readback)
  kheaders: Do not regenerate archive if config is not changed
  kheaders: Move from proc to sysfs
  lkdtm/bugs: Adjust recursion test to avoid elision
  lkdtm/usercopy: Moves the KERNEL_DS test to non-canonical
</pre>
</div>
</content>
</entry>
<entry>
<title>test_firmware: Use correct snprintf() limit</title>
<updated>2019-05-24T19:03:28+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2019-05-15T09:33:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bd17cc5a20ae9aaa3ed775f360b75ff93cd66a1d'/>
<id>bd17cc5a20ae9aaa3ed775f360b75ff93cd66a1d</id>
<content type='text'>
The limit here is supposed to be how much of the page is left, but it's
just using PAGE_SIZE as the limit.

The other thing to remember is that snprintf() returns the number of
bytes which would have been copied if we had had enough room.  So that
means that if we run out of space then this code would end up passing a
negative value as the limit and the kernel would print an error message.
I have change the code to use scnprintf() which returns the number of
bytes that were successfully printed (not counting the NUL terminator).

Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The limit here is supposed to be how much of the page is left, but it's
just using PAGE_SIZE as the limit.

The other thing to remember is that snprintf() returns the number of
bytes which would have been copied if we had had enough room.  So that
means that if we run out of space then this code would end up passing a
negative value as the limit and the kernel would print an error message.
I have change the code to use scnprintf() which returns the number of
bytes that were successfully printed (not counting the NUL terminator).

Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>treewide: Add SPDX license identifier for more missed files</title>
<updated>2019-05-21T08:50:45+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-05-19T12:08:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=09c434b8a0047c69e48499de0107de312901e798'/>
<id>09c434b8a0047c69e48499de0107de312901e798</id>
<content type='text'>
Add SPDX license identifiers to all files which:

 - Have no license information of any form

 - Have MODULE_LICENCE("GPL*") inside which was used in the initial
   scan/conversion to ignore the file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add SPDX license identifiers to all files which:

 - Have no license information of any form

 - Have MODULE_LICENCE("GPL*") inside which was used in the initial
   scan/conversion to ignore the file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
