<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git, branch toradex_5.4.y</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Revert "Revert "mtd: rawnand: gpmi: Fix setting busy timeout setting""</title>
<updated>2024-02-07T17:50:27+00:00</updated>
<author>
<name>Max Krummenacher</name>
<email>max.krummenacher@toradex.com</email>
</author>
<published>2024-02-07T15:17:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0dae0c54feafd327366df4eac6f8948d2b167afa'/>
<id>0dae0c54feafd327366df4eac6f8948d2b167afa</id>
<content type='text'>
This reverts commit 15a3adfe75937c9e4e0e48f0ed40dd39a0e526e2.

The backport of [1] relies on having [2] also backported. Having only
one of the two results in a bogus hw-&gt;timing1 setting.

If only [2] is backportet the 16 bit register value likely underflows
resulting in a busy_wait_timeout of 0.
Or if only [1] is applied the value likely overflows with chances of
having last 16 LSBs all 0 which would then result in a
busy_wait_timeout of 0 too.

Both cases may lead to NAND data corruption, e.g. on a Colibri iMX7
setup this has been seen.

[1] commit 0fddf9ad06fd ("mtd: rawnand: gpmi: Set WAIT_FOR_READY
timeout based on program/erase times")
[2] commit 06781a5026350 ("mtd: rawnand: gpmi: Fix setting busy
timeout setting")

Upstream-Status: Submitted [https://lore.kernel.org/all/20240207174911.870822-1-max.oss.09@gmail.com/]
Signed-off-by: Max Krummenacher &lt;max.krummenacher@toradex.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 15a3adfe75937c9e4e0e48f0ed40dd39a0e526e2.

The backport of [1] relies on having [2] also backported. Having only
one of the two results in a bogus hw-&gt;timing1 setting.

If only [2] is backportet the 16 bit register value likely underflows
resulting in a busy_wait_timeout of 0.
Or if only [1] is applied the value likely overflows with chances of
having last 16 LSBs all 0 which would then result in a
busy_wait_timeout of 0 too.

Both cases may lead to NAND data corruption, e.g. on a Colibri iMX7
setup this has been seen.

[1] commit 0fddf9ad06fd ("mtd: rawnand: gpmi: Set WAIT_FOR_READY
timeout based on program/erase times")
[2] commit 06781a5026350 ("mtd: rawnand: gpmi: Fix setting busy
timeout setting")

Upstream-Status: Submitted [https://lore.kernel.org/all/20240207174911.870822-1-max.oss.09@gmail.com/]
Signed-off-by: Max Krummenacher &lt;max.krummenacher@toradex.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'v5.4.264' into toradex_5.4.y</title>
<updated>2024-02-05T15:36:18+00:00</updated>
<author>
<name>Max Krummenacher</name>
<email>max.krummenacher@toradex.com</email>
</author>
<published>2024-02-05T15:35:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=340d0000d1e277a5ec64e5bd903dab8ed1df1860'/>
<id>340d0000d1e277a5ec64e5bd903dab8ed1df1860</id>
<content type='text'>
This is the 5.4.264 stable release

Conflicts:
	drivers/pci/controller/dwc/pci-imx6.c
		commit 0f31993721f92 ("PCI: imx6: Install the fault
		handler only on compatible match") overlaps with our
		not mainlined THUMB work.
		Keep both additions
	sound/soc/codecs/sgtl5000.c
		commit c062676528865 (ASoC: sgtl5000: Reset the
		CHIP_CLK_CTRL reg on remove") with a backport of a
		"fixes" commit.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is the 5.4.264 stable release

Conflicts:
	drivers/pci/controller/dwc/pci-imx6.c
		commit 0f31993721f92 ("PCI: imx6: Install the fault
		handler only on compatible match") overlaps with our
		not mainlined THUMB work.
		Keep both additions
	sound/soc/codecs/sgtl5000.c
		commit c062676528865 (ASoC: sgtl5000: Reset the
		CHIP_CLK_CTRL reg on remove") with a backport of a
		"fixes" commit.
</pre>
</div>
</content>
</entry>
<entry>
<title>toradex-imx_v6_v7_defconfig: Add INA2XX and NAU8822 configs</title>
<updated>2024-01-25T16:23:45+00:00</updated>
<author>
<name>Hiago De Franco</name>
<email>hiago.franco@toradex.com</email>
</author>
<published>2024-01-17T20:15:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4f79a6f97a8b85a7f887723616825b2427e38059'/>
<id>4f79a6f97a8b85a7f887723616825b2427e38059</id>
<content type='text'>
Apalis Evaluation Board v1.2 added some new on-board chips (compared to
v1.1) that are not yet enabled in the Linux kernel defconfig file:

- Audio codec NAU88C22YG
- Current/Voltage measurement INA219

So add the necessary drivers as modules to support these new devices.

Upstream-Status: Inappropriate [configuration]

- For mainline, our defconfig is built by merging the mainline
  configuration called imx_v6_v7_defconfig with the one inside
  meta-toradex-bsp-common called toradex-imx_v6_v7_defconfig. These
  configurations are already enabled there.

Related-to: ELB-5534
Signed-off-by: Hiago De Franco &lt;hiago.franco@toradex.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Apalis Evaluation Board v1.2 added some new on-board chips (compared to
v1.1) that are not yet enabled in the Linux kernel defconfig file:

- Audio codec NAU88C22YG
- Current/Voltage measurement INA219

So add the necessary drivers as modules to support these new devices.

Upstream-Status: Inappropriate [configuration]

- For mainline, our defconfig is built by merging the mainline
  configuration called imx_v6_v7_defconfig with the one inside
  meta-toradex-bsp-common called toradex-imx_v6_v7_defconfig. These
  configurations are already enabled there.

Related-to: ELB-5534
Signed-off-by: Hiago De Franco &lt;hiago.franco@toradex.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: dts: nxp: imx: Add support for Apalis Evaluation Board v1.2</title>
<updated>2024-01-24T15:55:26+00:00</updated>
<author>
<name>Hiago De Franco</name>
<email>hiago.franco@toradex.com</email>
</author>
<published>2024-01-16T14:35:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9970d5a44f5b981635494868964db52bc485d2c2'/>
<id>9970d5a44f5b981635494868964db52bc485d2c2</id>
<content type='text'>
Add support for the new Apalis Evaluation Board v1.2. Because
only the imx6q-apalis-eval.dts was available, the imx6q-apalis-eval.dtsi
has been created which has common hardware configurations for v1.0, v1.1
and v1.2. Both imx6q-apalis-eval.dts and imx6q-apalis-eval-v1.2.dts
files include imx6q-apalis-eval.dtsi.

Versions 1.0 and 1.1 are compatible with each other and should
use imx6q-apalis-eval.dts file. Now for v1.2, the new device-tree file
should be used.

Upstream-Status: Submitted [https://lore.kernel.org/all/20240124141849.26254-1-hiagofranco@gmail.com/]
Related-to: ELB-5534
Signed-off-by: Hiago De Franco &lt;hiago.franco@toradex.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for the new Apalis Evaluation Board v1.2. Because
only the imx6q-apalis-eval.dts was available, the imx6q-apalis-eval.dtsi
has been created which has common hardware configurations for v1.0, v1.1
and v1.2. Both imx6q-apalis-eval.dts and imx6q-apalis-eval-v1.2.dts
files include imx6q-apalis-eval.dtsi.

Versions 1.0 and 1.1 are compatible with each other and should
use imx6q-apalis-eval.dts file. Now for v1.2, the new device-tree file
should be used.

Upstream-Status: Submitted [https://lore.kernel.org/all/20240124141849.26254-1-hiagofranco@gmail.com/]
Related-to: ELB-5534
Signed-off-by: Hiago De Franco &lt;hiago.franco@toradex.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: mwifiex: configure BSSID consistently when starting AP</title>
<updated>2023-12-18T10:41:26+00:00</updated>
<author>
<name>David Lin</name>
<email>yu-hao.lin@nxp.com</email>
</author>
<published>2023-12-15T00:51:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9a0c518ec7dad349f31ad2d6bb5a7204b9203bab'/>
<id>9a0c518ec7dad349f31ad2d6bb5a7204b9203bab</id>
<content type='text'>
AP BSSID configuration is missing at AP start.
Without this fix, FW returns STA interface MAC address after first init.
When hostapd restarts, it gets MAC address from netdev before driver
sets STA MAC to netdev again. Now MAC address between hostapd and net
interface are different causes STA cannot connect to AP.
After that MAC address of uap0 mlan0 become the same. And issue
disappears after following hostapd restart (another issue is AP/STA MAC
address become the same).
This patch fixes the issue cleanly.

Upstream-Status: Submitted [https://lore.kernel.org/all/20231215005118.17031-1-yu-hao.lin@nxp.com/]

Signed-off-by: David Lin &lt;yu-hao.lin@nxp.com&gt;
Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers")
Cc: stable@vger.kernel.org
Reviewed-by: Francesco Dolcini &lt;francesco.dolcini@toradex.com&gt;
Tested-by: Rafael Beims &lt;rafael.beims@toradex.com&gt; # Verdin iMX8MP/SD8997 SD
Acked-by: Brian Norris &lt;briannorris@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
AP BSSID configuration is missing at AP start.
Without this fix, FW returns STA interface MAC address after first init.
When hostapd restarts, it gets MAC address from netdev before driver
sets STA MAC to netdev again. Now MAC address between hostapd and net
interface are different causes STA cannot connect to AP.
After that MAC address of uap0 mlan0 become the same. And issue
disappears after following hostapd restart (another issue is AP/STA MAC
address become the same).
This patch fixes the issue cleanly.

Upstream-Status: Submitted [https://lore.kernel.org/all/20231215005118.17031-1-yu-hao.lin@nxp.com/]

Signed-off-by: David Lin &lt;yu-hao.lin@nxp.com&gt;
Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers")
Cc: stable@vger.kernel.org
Reviewed-by: Francesco Dolcini &lt;francesco.dolcini@toradex.com&gt;
Tested-by: Rafael Beims &lt;rafael.beims@toradex.com&gt; # Verdin iMX8MP/SD8997 SD
Acked-by: Brian Norris &lt;briannorris@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Linux 5.4.264</title>
<updated>2023-12-13T17:18:18+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-12-13T17:18:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=16e6e107a688046df37976fb6d7310e886c8115d'/>
<id>16e6e107a688046df37976fb6d7310e886c8115d</id>
<content type='text'>
Link: https://lore.kernel.org/r/20231211182015.049134368@linuxfoundation.org
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Harshit Mogalapalli &lt;harshit.m.mogalapalli@oracle.com&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&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>
Link: https://lore.kernel.org/r/20231211182015.049134368@linuxfoundation.org
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Harshit Mogalapalli &lt;harshit.m.mogalapalli@oracle.com&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>devcoredump: Send uevent once devcd is ready</title>
<updated>2023-12-13T17:18:18+00:00</updated>
<author>
<name>Mukesh Ojha</name>
<email>quic_mojha@quicinc.com</email>
</author>
<published>2023-11-17T14:49:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=06bcac5c51519566d45f9e21b85d56457e12fcc2'/>
<id>06bcac5c51519566d45f9e21b85d56457e12fcc2</id>
<content type='text'>
[ Upstream commit af54d778a03853801d681c98c0c2a6c316ef9ca7 ]

dev_coredumpm() creates a devcoredump device and adds it
to the core kernel framework which eventually end up
sending uevent to the user space and later creates a
symbolic link to the failed device. An application
running in userspace may be interested in this symbolic
link to get the name of the failed device.

In a issue scenario, once uevent sent to the user space
it start reading '/sys/class/devcoredump/devcdX/failing_device'
to get the actual name of the device which might not been
created and it is in its path of creation.

To fix this, suppress sending uevent till the failing device
symbolic link gets created and send uevent once symbolic
link is created successfully.

Fixes: 833c95456a70 ("device coredump: add new device coredump class")
Signed-off-by: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1700232572-25823-1-git-send-email-quic_mojha@quicinc.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 af54d778a03853801d681c98c0c2a6c316ef9ca7 ]

dev_coredumpm() creates a devcoredump device and adds it
to the core kernel framework which eventually end up
sending uevent to the user space and later creates a
symbolic link to the failed device. An application
running in userspace may be interested in this symbolic
link to get the name of the failed device.

In a issue scenario, once uevent sent to the user space
it start reading '/sys/class/devcoredump/devcdX/failing_device'
to get the actual name of the device which might not been
created and it is in its path of creation.

To fix this, suppress sending uevent till the failing device
symbolic link gets created and send uevent once symbolic
link is created successfully.

Fixes: 833c95456a70 ("device coredump: add new device coredump class")
Signed-off-by: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1700232572-25823-1-git-send-email-quic_mojha@quicinc.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>devcoredump : Serialize devcd_del work</title>
<updated>2023-12-13T17:18:18+00:00</updated>
<author>
<name>Mukesh Ojha</name>
<email>quic_mojha@quicinc.com</email>
</author>
<published>2022-09-13T12:50:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c6a1282e530d6e34da292857ec4c230c3a289199'/>
<id>c6a1282e530d6e34da292857ec4c230c3a289199</id>
<content type='text'>
[ Upstream commit 01daccf748323dfc61112f474cf2ba81015446b0 ]

In following scenario(diagram), when one thread X running dev_coredumpm()
adds devcd device to the framework which sends uevent notification to
userspace and another thread Y reads this uevent and call to
devcd_data_write() which eventually try to delete the queued timer that
is not initialized/queued yet.

So, debug object reports some warning and in the meantime, timer is
initialized and queued from X path. and from Y path, it gets reinitialized
again and timer-&gt;entry.pprev=NULL and try_to_grab_pending() stucks.

To fix this, introduce mutex and a boolean flag to serialize the behaviour.

 	cpu0(X)			                cpu1(Y)

    dev_coredump() uevent sent to user space
    device_add()  ======================&gt; user space process Y reads the
                                          uevents writes to devcd fd
                                          which results into writes to

                                         devcd_data_write()
                                           mod_delayed_work()
                                             try_to_grab_pending()
                                               del_timer()
                                                 debug_assert_init()
   INIT_DELAYED_WORK()
   schedule_delayed_work()
                                                   debug_object_fixup()
                                                     timer_fixup_assert_init()
                                                       timer_setup()
                                                         do_init_timer()
                                                       /*
                                                        Above call reinitializes
                                                        the timer to
                                                        timer-&gt;entry.pprev=NULL
                                                        and this will be checked
                                                        later in timer_pending() call.
                                                       */
                                                 timer_pending()
                                                  !hlist_unhashed_lockless(&amp;timer-&gt;entry)
                                                    !h-&gt;pprev
                                                /*
                                                  del_timer() checks h-&gt;pprev and finds
                                                  it to be NULL due to which
                                                  try_to_grab_pending() stucks.
                                                */

Link: https://lore.kernel.org/lkml/2e1f81e2-428c-f11f-ce92-eb11048cb271@quicinc.com/
Signed-off-by: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Link: https://lore.kernel.org/r/1663073424-13663-1-git-send-email-quic_mojha@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Stable-dep-of: af54d778a038 ("devcoredump: Send uevent once devcd is ready")
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 01daccf748323dfc61112f474cf2ba81015446b0 ]

In following scenario(diagram), when one thread X running dev_coredumpm()
adds devcd device to the framework which sends uevent notification to
userspace and another thread Y reads this uevent and call to
devcd_data_write() which eventually try to delete the queued timer that
is not initialized/queued yet.

So, debug object reports some warning and in the meantime, timer is
initialized and queued from X path. and from Y path, it gets reinitialized
again and timer-&gt;entry.pprev=NULL and try_to_grab_pending() stucks.

To fix this, introduce mutex and a boolean flag to serialize the behaviour.

 	cpu0(X)			                cpu1(Y)

    dev_coredump() uevent sent to user space
    device_add()  ======================&gt; user space process Y reads the
                                          uevents writes to devcd fd
                                          which results into writes to

                                         devcd_data_write()
                                           mod_delayed_work()
                                             try_to_grab_pending()
                                               del_timer()
                                                 debug_assert_init()
   INIT_DELAYED_WORK()
   schedule_delayed_work()
                                                   debug_object_fixup()
                                                     timer_fixup_assert_init()
                                                       timer_setup()
                                                         do_init_timer()
                                                       /*
                                                        Above call reinitializes
                                                        the timer to
                                                        timer-&gt;entry.pprev=NULL
                                                        and this will be checked
                                                        later in timer_pending() call.
                                                       */
                                                 timer_pending()
                                                  !hlist_unhashed_lockless(&amp;timer-&gt;entry)
                                                    !h-&gt;pprev
                                                /*
                                                  del_timer() checks h-&gt;pprev and finds
                                                  it to be NULL due to which
                                                  try_to_grab_pending() stucks.
                                                */

Link: https://lore.kernel.org/lkml/2e1f81e2-428c-f11f-ce92-eb11048cb271@quicinc.com/
Signed-off-by: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Link: https://lore.kernel.org/r/1663073424-13663-1-git-send-email-quic_mojha@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Stable-dep-of: af54d778a038 ("devcoredump: Send uevent once devcd is ready")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>smb: client: fix potential NULL deref in parse_dfs_referrals()</title>
<updated>2023-12-13T17:18:17+00:00</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.com</email>
</author>
<published>2023-12-06T00:49:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d99376b70247394b39307051f994060a085a417e'/>
<id>d99376b70247394b39307051f994060a085a417e</id>
<content type='text'>
[ Upstream commit 92414333eb375ed64f4ae92d34d579e826936480 ]

If server returned no data for FSCTL_DFS_GET_REFERRALS, @dfs_rsp will
remain NULL and then parse_dfs_referrals() will dereference it.

Fix this by returning -EIO when no output data is returned.

Besides, we can't fix it in SMB2_ioctl() as some FSCTLs are allowed to
return no data as per MS-SMB2 2.2.32.

Fixes: 9d49640a21bf ("CIFS: implement get_dfs_refer for SMB2+")
Cc: stable@vger.kernel.org
Reported-by: Robert Morris &lt;rtm@csail.mit.edu&gt;
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&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 92414333eb375ed64f4ae92d34d579e826936480 ]

If server returned no data for FSCTL_DFS_GET_REFERRALS, @dfs_rsp will
remain NULL and then parse_dfs_referrals() will dereference it.

Fix this by returning -EIO when no output data is returned.

Besides, we can't fix it in SMB2_ioctl() as some FSCTLs are allowed to
return no data as per MS-SMB2 2.2.32.

Fixes: 9d49640a21bf ("CIFS: implement get_dfs_refer for SMB2+")
Cc: stable@vger.kernel.org
Reported-by: Robert Morris &lt;rtm@csail.mit.edu&gt;
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cifs: Fix non-availability of dedup breaking generic/304</title>
<updated>2023-12-13T17:18:17+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2023-12-04T14:01:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ab5813bb20711a8e3493b152e50b3dda3aed5858'/>
<id>ab5813bb20711a8e3493b152e50b3dda3aed5858</id>
<content type='text'>
[ Upstream commit 691a41d8da4b34fe72f09393505f55f28a8f34ec ]

Deduplication isn't supported on cifs, but cifs doesn't reject it, instead
treating it as extent duplication/cloning.  This can cause generic/304 to go
silly and run for hours on end.

Fix cifs to indicate EOPNOTSUPP if REMAP_FILE_DEDUP is set in
-&gt;remap_file_range().

Note that it's unclear whether or not commit b073a08016a1 is meant to cause
cifs to return an error if REMAP_FILE_DEDUP.

Fixes: b073a08016a1 ("cifs: fix that return -EINVAL when do dedupe operation")
Cc: stable@vger.kernel.org
Suggested-by: Dave Chinner &lt;david@fromorbit.com&gt;
cc: Xiaoli Feng &lt;fengxiaoli0714@gmail.com&gt;
cc: Shyam Prasad N &lt;nspmangalore@gmail.com&gt;
cc: Rohith Surabattula &lt;rohiths.msft@gmail.com&gt;
cc: Jeff Layton &lt;jlayton@kernel.org&gt;
cc: Darrick Wong &lt;darrick.wong@oracle.com&gt;
cc: fstests@vger.kernel.org
cc: linux-cifs@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
Link: https://lore.kernel.org/r/3876191.1701555260@warthog.procyon.org.uk/
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&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 691a41d8da4b34fe72f09393505f55f28a8f34ec ]

Deduplication isn't supported on cifs, but cifs doesn't reject it, instead
treating it as extent duplication/cloning.  This can cause generic/304 to go
silly and run for hours on end.

Fix cifs to indicate EOPNOTSUPP if REMAP_FILE_DEDUP is set in
-&gt;remap_file_range().

Note that it's unclear whether or not commit b073a08016a1 is meant to cause
cifs to return an error if REMAP_FILE_DEDUP.

Fixes: b073a08016a1 ("cifs: fix that return -EINVAL when do dedupe operation")
Cc: stable@vger.kernel.org
Suggested-by: Dave Chinner &lt;david@fromorbit.com&gt;
cc: Xiaoli Feng &lt;fengxiaoli0714@gmail.com&gt;
cc: Shyam Prasad N &lt;nspmangalore@gmail.com&gt;
cc: Rohith Surabattula &lt;rohiths.msft@gmail.com&gt;
cc: Jeff Layton &lt;jlayton@kernel.org&gt;
cc: Darrick Wong &lt;darrick.wong@oracle.com&gt;
cc: fstests@vger.kernel.org
cc: linux-cifs@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
Link: https://lore.kernel.org/r/3876191.1701555260@warthog.procyon.org.uk/
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
