This is the start of the stable review cycle for the 4.19.145 release.
There are 8 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun, 13 Sep 2020 12:54:13 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.145-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.19.145-rc1
Roi Dayan <[email protected]>
net/mlx5e: Don't support phys switch id if not in switchdev mode
Jakub Kicinski <[email protected]>
net: disable netpoll on fresh napis
Tetsuo Handa <[email protected]>
tipc: fix shutdown() of connectionless socket
Xin Long <[email protected]>
sctp: not disable bh in the whole sctp_get_port_local()
Kamil Lorenc <[email protected]>
net: usb: dm9601: Add USB ID of Keenetic Plus DSL
Paul Moore <[email protected]>
netlabel: fix problems with mapping removal
Jens Axboe <[email protected]>
block: ensure bdi->io_pages is always initialized
Takashi Sakamoto <[email protected]>
ALSA; firewire-tascam: exclude Tascam FE-8 from detection
-------------
Diffstat:
Makefile | 4 +-
block/blk-core.c | 2 +
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 2 +-
drivers/net/usb/dm9601.c | 4 ++
net/core/dev.c | 3 +-
net/core/netpoll.c | 2 +-
net/netlabel/netlabel_domainhash.c | 59 ++++++++++++------------
net/sctp/socket.c | 16 +++----
net/tipc/socket.c | 9 ++--
sound/firewire/tascam/tascam.c | 30 +++++++++++-
10 files changed, 83 insertions(+), 48 deletions(-)
From: Jakub Kicinski <[email protected]>
[ Upstream commit 96e97bc07e90f175a8980a22827faf702ca4cb30 ]
napi_disable() makes sure to set the NAPI_STATE_NPSVC bit to prevent
netpoll from accessing rings before init is complete. However, the
same is not done for fresh napi instances in netif_napi_add(),
even though we expect NAPI instances to be added as disabled.
This causes crashes during driver reconfiguration (enabling XDP,
changing the channel count) - if there is any printk() after
netif_napi_add() but before napi_enable().
To ensure memory ordering is correct we need to use RCU accessors.
Reported-by: Rob Sherwood <[email protected]>
Fixes: 2d8bff12699a ("netpoll: Close race condition between poll_one_napi and napi_disable")
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/dev.c | 3 ++-
net/core/netpoll.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6196,12 +6196,13 @@ void netif_napi_add(struct net_device *d
pr_err_once("netif_napi_add() called with weight %d on device %s\n",
weight, dev->name);
napi->weight = weight;
- list_add(&napi->dev_list, &dev->napi_list);
napi->dev = dev;
#ifdef CONFIG_NETPOLL
napi->poll_owner = -1;
#endif
set_bit(NAPI_STATE_SCHED, &napi->state);
+ set_bit(NAPI_STATE_NPSVC, &napi->state);
+ list_add_rcu(&napi->dev_list, &dev->napi_list);
napi_hash_add(napi);
}
EXPORT_SYMBOL(netif_napi_add);
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -161,7 +161,7 @@ static void poll_napi(struct net_device
struct napi_struct *napi;
int cpu = smp_processor_id();
- list_for_each_entry(napi, &dev->napi_list, dev_list) {
+ list_for_each_entry_rcu(napi, &dev->napi_list, dev_list) {
if (cmpxchg(&napi->poll_owner, -1, cpu) == -1) {
poll_one_napi(napi);
smp_store_release(&napi->poll_owner, -1);
From: Jens Axboe <[email protected]>
[ Upstream commit de1b0ee490eafdf65fac9eef9925391a8369f2dc ]
If a driver leaves the limit settings as the defaults, then we don't
initialize bdi->io_pages. This means that file systems may need to
work around bdi->io_pages == 0, which is somewhat messy.
Initialize the default value just like we do for ->ra_pages.
Cc: [email protected]
Fixes: 9491ae4aade6 ("mm: don't cap request size based on read-ahead setting")
Reported-by: OGAWA Hirofumi <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
block/blk-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index ea33d6abdcfc9..ce3710404544c 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1036,6 +1036,8 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id,
q->backing_dev_info->ra_pages =
(VM_MAX_READAHEAD * 1024) / PAGE_SIZE;
+ q->backing_dev_info->io_pages =
+ (VM_MAX_READAHEAD * 1024) / PAGE_SIZE;
q->backing_dev_info->capabilities = BDI_CAP_CGROUP_WRITEBACK;
q->backing_dev_info->name = "block";
q->node = node_id;
--
2.25.1
From: Takashi Sakamoto <[email protected]>
Tascam FE-8 is known to support communication by asynchronous transaction
only. The support can be implemented in userspace application and
snd-firewire-ctl-services project has the support. However, ALSA
firewire-tascam driver is bound to the model.
This commit changes device entries so that the model is excluded. In a
commit 53b3ffee7885 ("ALSA: firewire-tascam: change device probing
processing"), I addressed to the concern that version field in
configuration differs depending on installed firmware. However, as long
as I checked, the version number is fixed. It's safe to return version
number back to modalias.
Fixes: 53b3ffee7885 ("ALSA: firewire-tascam: change device probing processing")
Cc: <[email protected]> # 4.4+
Signed-off-by: Takashi Sakamoto <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
---
sound/firewire/tascam/tascam.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/sound/firewire/tascam/tascam.c b/sound/firewire/tascam/tascam.c
index d3fdc463a884e..1e61cdce28952 100644
--- a/sound/firewire/tascam/tascam.c
+++ b/sound/firewire/tascam/tascam.c
@@ -225,11 +225,39 @@ static void snd_tscm_remove(struct fw_unit *unit)
}
static const struct ieee1394_device_id snd_tscm_id_table[] = {
+ // Tascam, FW-1884.
{
.match_flags = IEEE1394_MATCH_VENDOR_ID |
- IEEE1394_MATCH_SPECIFIER_ID,
+ IEEE1394_MATCH_SPECIFIER_ID |
+ IEEE1394_MATCH_VERSION,
.vendor_id = 0x00022e,
.specifier_id = 0x00022e,
+ .version = 0x800000,
+ },
+ // Tascam, FE-8 (.version = 0x800001)
+ // This kernel module doesn't support FE-8 because the most of features
+ // can be implemented in userspace without any specific support of this
+ // module.
+ //
+ // .version = 0x800002 is unknown.
+ //
+ // Tascam, FW-1082.
+ {
+ .match_flags = IEEE1394_MATCH_VENDOR_ID |
+ IEEE1394_MATCH_SPECIFIER_ID |
+ IEEE1394_MATCH_VERSION,
+ .vendor_id = 0x00022e,
+ .specifier_id = 0x00022e,
+ .version = 0x800003,
+ },
+ // Tascam, FW-1804.
+ {
+ .match_flags = IEEE1394_MATCH_VENDOR_ID |
+ IEEE1394_MATCH_SPECIFIER_ID |
+ IEEE1394_MATCH_VERSION,
+ .vendor_id = 0x00022e,
+ .specifier_id = 0x00022e,
+ .version = 0x800004,
},
/* FE-08 requires reverse-engineering because it just has faders. */
{}
--
2.25.1
From: Roi Dayan <[email protected]>
Support for phys switch id ndo added for representors and if
we do not have representors there is no need to support it.
Since each port return different switch id supporting this
block support for creating bond over PFs and attaching to bridge
in legacy mode.
This bug doesn't exist upstream as the code got refactored and the
netdev api is totally different.
Fixes: cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors")
Signed-off-by: Roi Dayan <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -198,7 +198,7 @@ int mlx5e_attr_get(struct net_device *de
struct mlx5_eswitch_rep *rep = rpriv->rep;
struct mlx5_eswitch *esw = priv->mdev->priv.eswitch;
- if (esw->mode == SRIOV_NONE)
+ if (esw->mode != SRIOV_OFFLOADS)
return -EOPNOTSUPP;
switch (attr->id) {
On 9/11/20 6:54 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.145 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 13 Sep 2020 12:54:13 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.145-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
On Fri, 11 Sep 2020 at 18:31, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.145 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 13 Sep 2020 12:54:13 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.145-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <[email protected]>
Summary
------------------------------------------------------------------------
kernel: 4.19.145-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: dc4669f837af87843c89b6eaccfe395fd83bc1df
git describe: v4.19.144-9-gdc4669f837af
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.144-9-gdc4669f837af
No regressions (compared to build v4.19.144)
No fixes (compared to build v4.19.144)
Ran 19565 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* linux-log-parser
* network-basic-tests
* perf
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* v4l2-compliance
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* ssuite
--
Linaro LKFT
https://lkft.linaro.org
Hi!
> From: Takashi Sakamoto <[email protected]>
>
> Tascam FE-8 is known to support communication by asynchronous transaction
> only. The support can be implemented in userspace application and
> snd-firewire-ctl-services project has the support. However, ALSA
> firewire-tascam driver is bound to the model.
This one is in upstream, but is not marked as such. AFAICT it is
0bd8bce897b6697bbc286b8ba473aa0705fe394b.
Unfortunately it is too late to fix that now.
This one was scheduled to be released at "Responses should be made by
Sun, 13 Sep 2020 12:54:13 +0000.". But it was released day earlier:
"Date: Sat, 12 Sep 2020 14:42:49 +0200".
Could you actually follow published schedule? Could the schedule be
made a bit less agressive over the weekends?
Could you cc me release announcements on [email protected] email?
Thanks and best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Sep 14, 2020 at 09:47:31AM +0200, Pavel Machek wrote:
> Hi!
>
> > From: Takashi Sakamoto <[email protected]>
> >
> > Tascam FE-8 is known to support communication by asynchronous transaction
> > only. The support can be implemented in userspace application and
> > snd-firewire-ctl-services project has the support. However, ALSA
> > firewire-tascam driver is bound to the model.
>
> This one is in upstream, but is not marked as such. AFAICT it is
> 0bd8bce897b6697bbc286b8ba473aa0705fe394b.
>
> Unfortunately it is too late to fix that now.
>
> This one was scheduled to be released at "Responses should be made by
> Sun, 13 Sep 2020 12:54:13 +0000.". But it was released day earlier:
> "Date: Sat, 12 Sep 2020 14:42:49 +0200".
>
> Could you actually follow published schedule?
If all of the reported testing systems come back successful, there is no
need to wait any longer.
> Could you cc me release announcements on [email protected] email?
Will add you to the list, thanks.
greg k-h
Hi!
> > Unfortunately it is too late to fix that now.
> >
> > This one was scheduled to be released at "Responses should be made by
> > Sun, 13 Sep 2020 12:54:13 +0000.". But it was released day earlier:
> > "Date: Sat, 12 Sep 2020 14:42:49 +0200".
> >
> > Could you actually follow published schedule?
>
> If all of the reported testing systems come back successful, there is no
> need to wait any longer.
Well, then perhaps you should not publish the schedule, as it is confusing?
> > Could you cc me release announcements on [email protected] email?
>
> Will add you to the list, thanks.
Thank you,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany