5.4.119-rc1 review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 166/244 HSI: core: fix resource leaks in hsi_add_client_from_dt()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit 5c08b0f75575648032f309a6f58294453423ed93 ]
If some of the allocations fail between the dev_set_name() and the device_register() then the name will not be freed. Fix this by moving dev_set_name() directly in front of the call to device_register().
--- drivers/hsi/hsi_core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/hsi/hsi_core.c +1 -2
@@ -210,8 +210,6 @@ static void hsi_add_client_from_dt(struct hsi_port *port,if (err) goto err; -dev_set_name (&cl->device,"%s" , name); - err =hsi_of_property_parse_mode (client,"hsi-mode" , &mode);if (err) { err = hsi_of_property_parse_mode(client, "hsi-rx-mode",
@@ -293,6 +291,7 @@ static void hsi_add_client_from_dt(struct hsi_port *port, cl->device.release = hsi_client_release; cl->device.of_node = client; +dev_set_name (&cl->device,"%s" , name);if (device_register (&cl->device) <0 ) {pr_err ("hsi: failed to register client: %s\n" , name);put_device (&cl->device);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 167/244 x86/events/amd/iommu: Fix sysfs type mismatch
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
[ Upstream commit de5bc7b425d4c27ae5faa00ea7eb6b9780b9a355 ]
dev_attr_show() calls _iommu_event_show() via an indirect call but _iommu_event_show()'s type does not currently match the type of the show() member in 'struct device_attribute', resulting in a Control Flow Integrity violation.
$ cat /sys/devices/amd_iommu_1/events/mem_dte_hit csource=0x0a
$ dmesg | grep "CFI failure" [ 3526.735140] CFI failure (target: _iommu_event_show...):
Change _iommu_event_show() and 'struct amd_iommu_event_desc' to 'struct device_attribute' so that there is no more CFI violation.
--- arch/x86/events/amd/iommu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/x86/events/amd/iommu.c +3 -3
@@ -81,12 +81,12 @@ static struct attribute_group amd_iommu_events_group = { };struct amd_iommu_event_desc { -struct kobj_attribute attr; +struct device_attribute attr;const char *event; }; -static ssize_t _iommu_event_show (struct kobject *kobj, -struct kobj_attribute *attr,char *buf) +static ssize_t _iommu_event_show (struct device *dev, +struct device_attribute *attr,char *buf) {struct amd_iommu_event_desc *event = container_of(attr, struct amd_iommu_event_desc, attr);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 168/244 sched/debug: Fix cgroup_path[] serialization
In reply to Greg Kroah-HartmanFrom: Waiman Long <[email protected]>
[ Upstream commit ad789f84c9a145f8a18744c0387cec22ec51651e ]
The handling of sysrq key can be activated by echoing the key to /proc/sysrq-trigger or via the magic key sequence typed into a terminal that is connected to the system in some way (serial, USB or other mean). In the former case, the handling is done in a user context. In the latter case, it is likely to be in an interrupt context.
Currently in print_cpu() of kernel/sched/debug.c, sched_debug_lock is taken with interrupt disabled for the whole duration of the calls to print_*_stats() and print_rq() which could last for the quite some time if the information dump happens on the serial console.
If the system has many cpus and the sched_debug_lock is somehow busy (e.g. parallel sysrq-t), the system may hit a hard lockup panic depending on the actually serial console implementation of the system.
The purpose of sched_debug_lock is to serialize the use of the global cgroup_path[] buffer in print_cpu(). The rests of the printk calls don't need serialization from sched_debug_lock.
Calling printk() with interrupt disabled can still be problematic if multiple instances are running. Allocating a stack buffer of PATH_MAX bytes is not feasible because of the limited size of the kernel stack.
The solution implemented in this patch is to allow only one caller at a time to use the full size group_path[], while other simultaneous callers will have to use shorter stack buffers with the possibility of path name truncation. A "..." suffix will be printed if truncation may have happened. The cgroup path name is provided for informational purpose only, so occasional path name truncation should not be a big problem.
--- kernel/sched/debug.c | 42 +++++++++++++++++++++++++++++------------- 1 file changed, 29 insertions(+), 13 deletions(-)
kernel/sched/debug.c +29 -13
@@ -8,8 +8,6 @@*/ #include "sched.h" -static DEFINE_SPINLOCK (sched_debug_lock); -/* * This allows printing both to /proc/sched_debug and * to the console
@@ -417,16 +415,37 @@ static void print_cfs_group_stats(struct seq_file *m, int cpu, struct task_group#endif #ifdef CONFIG_CGROUP_SCHED +static DEFINE_SPINLOCK (sched_debug_lock);static char group_path[PATH_MAX ]; -static char *task_group_path (struct task_group *tg) +static void task_group_path (struct task_group *tg,char *path,int plen) { -if (autogroup_path (tg, group_path,PATH_MAX )) -return group_path; +if (autogroup_path (tg, path, plen)) +return ; -cgroup_path (tg->css.cgroup, group_path,PATH_MAX ); +cgroup_path (tg->css.cgroup, path, plen); +} -return group_path; +/* +* Only 1 SEQ_printf_task_group_path() caller can use the full length +* group_path[] for cgroup path. Other simultaneous callers will have +* to use a shorter stack buffer. A "..." suffix is appended at the end +* of the stack buffer so that it will show up in case the output length +* matches the given buffer size to indicate possible path name truncation. +*/ +#define SEQ_printf_task_group_path(m, tg, fmt...) \ +{ \ + if (spin_trylock(&sched_debug_lock)) { \ + task_group_path(tg, group_path, sizeof(group_path)); \ + SEQ_printf(m, fmt, group_path); \ + spin_unlock(&sched_debug_lock); \ + } else { \ + char buf[128]; \ + char *bufend = buf + sizeof(buf) - 3; \ + task_group_path(tg, buf, bufend - buf); \ + strcpy(bufend - 1, "..."); \ + SEQ_printf(m, fmt, buf); \ + } \ }#endif
@@ -453,7 +472,7 @@ print_task(struct seq_file *m, struct rq *rq, struct task_struct *p)SEQ_printf (m," %d %d" ,task_node (p),task_numa_group_id (p));#endif #ifdef CONFIG_CGROUP_SCHED -SEQ_printf (m," %s" ,task_group_path (task_group (p))); + SEQ_printf_task_group_path(m, task_group(p), " %s")#endif SEQ_printf (m,"\n" );
@@ -490,7 +509,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)#ifdef CONFIG_FAIR_GROUP_SCHED SEQ_printf (m,"\n" ); -SEQ_printf (m,"cfs_rq[%d]:%s\n" , cpu,task_group_path (cfs_rq->tg)); +SEQ_printf_task_group_path (m, cfs_rq->tg,"cfs_rq[%d]:%s\n" , cpu);#else SEQ_printf (m,"\n" );SEQ_printf (m,"cfs_rq[%d]:\n" , cpu);
@@ -562,7 +581,7 @@ void print_rt_rq(struct seq_file *m, int cpu, struct rt_rq *rt_rq) {#ifdef CONFIG_RT_GROUP_SCHED SEQ_printf (m,"\n" ); -SEQ_printf (m,"rt_rq[%d]:%s\n" , cpu,task_group_path (rt_rq->tg)); +SEQ_printf_task_group_path (m, rt_rq->tg,"rt_rq[%d]:%s\n" , cpu);#else SEQ_printf (m,"\n" );SEQ_printf (m,"rt_rq[%d]:\n" , cpu);
@@ -614,7 +633,6 @@ void print_dl_rq(struct seq_file *m, int cpu, struct dl_rq *dl_rq)static void print_cpu (struct seq_file *m,int cpu) {struct rq *rq =cpu_rq (cpu); -unsigned long flags;#ifdef CONFIG_X86 {
@@ -666,13 +684,11 @@ do { \ }#undef P -spin_lock_irqsave (&sched_debug_lock, flags);print_cfs_stats (m, cpu);print_rt_stats (m, cpu);print_dl_stats (m, cpu);print_rq (m, rq, cpu); -spin_unlock_irqrestore (&sched_debug_lock, flags);SEQ_printf (m,"\n" ); }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 169/244 drivers/block/null_blk/main: Fix a double free in null_init.
In reply to Greg Kroah-HartmanFrom: Lv Yunlong <[email protected]>
[ Upstream commit 72ce11ddfa4e9e1879103581a60b7e34547eaa0a ]
In null_init, null_add_dev(dev) is called.
In null_add_dev, it calls null_free_zoned_dev(dev) to free dev->zones via kvfree(dev->zones) in out_cleanup_zone branch and returns err. Then null_init accept the err code and then calls null_free_dev(dev).
But in null_free_dev(dev), dev->zones is freed again by null_free_zoned_dev().
My patch set dev->zones to NULL in null_free_zoned_dev() after kvfree(dev->zones) is called, to avoid the double free.
--- drivers/block/null_blk_zoned.c | 1 + 1 file changed, 1 insertion(+)
drivers/block/null_blk_zoned.c +1 -0
@@ -73,6 +73,7 @@ int null_zone_init(struct nullb_device *dev)void null_zone_exit (struct nullb_device *dev) {kvfree (dev->zones); + dev->zones =NULL ; } int null_zone_report(struct gendisk *disk, sector_t sector,
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 170/244 HID: plantronics: Workaround for double volume key presses
In reply to Greg Kroah-HartmanFrom: Maxim Mikityanskiy <[email protected]>
[ Upstream commit f567d6ef8606fb427636e824c867229ecb5aefab ]
Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice for each volume key press. This patch adds a quirk to hid-plantronics for this product ID, which will ignore the second volume key press if it happens within 5 ms from the last one that was handled.
The patch was tested on the mentioned model only, it shouldn't affect other models, however, this quirk might be needed for them too. Auto-repeat (when a key is held pressed) is not affected, because the rate is about 3 times per second, which is far less frequent than once in 5 ms.
--- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-plantronics.c | 60 +++++++++++++++++++++++++++++++++-- include/linux/hid.h | 2 ++ 3 files changed, 61 insertions(+), 2 deletions(-)
drivers/hid/hid-ids.h +1 -0
@@ -932,6 +932,7 @@#define USB_DEVICE_ID_ORTEK_IHOME_IMAC_A210S 0x8003#define USB_VENDOR_ID_PLANTRONICS 0x047f +#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3220_SERIES 0xc056#define USB_VENDOR_ID_PANASONIC 0x04da#define USB_DEVICE_ID_PANABOARD_UBT780 0x1044
drivers/hid/hid-plantronics.c +58 -2
113 lines not on this page · raw message
include/linux/hid.h +2 -0
@@ -261,6 +261,8 @@ struct hid_item {#define HID_CP_SELECTION 0x000c0080#define HID_CP_MEDIASELECTION 0x000c0087#define HID_CP_SELECTDISC 0x000c00ba +#define HID_CP_VOLUMEUP 0x000c00e9 +#define HID_CP_VOLUMEDOWN 0x000c00ea#define HID_CP_PLAYBACKSPEED 0x000c00f1#define HID_CP_PROXIMITY 0x000c0109#define HID_CP_SPEAKERSYSTEM 0x000c0160
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 171/244 perf symbols: Fix dso__fprintf_symbols_by_name() to return the number of printed chars
In reply to Greg Kroah-HartmanFrom: Arnaldo Carvalho de Melo <[email protected]>
[ Upstream commit 210e4c89ef61432040c6cd828fefa441f4887186 ]
The 'ret' variable was initialized to zero but then it was not updated from the fprintf() return, fix it.
--- tools/perf/util/symbol_fprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/util/symbol_fprintf.c +1 -1
@@ -68,7 +68,7 @@ size_t dso__fprintf_symbols_by_name(struct dso *dso,for (nd =rb_first_cached (&dso->symbol_names); nd; nd =rb_next (nd)) { pos = rb_entry(nd, struct symbol_name_rb_node, rb_node); -fprintf (fp,"%s\n" , pos->sym.name); + ret +=fprintf (fp,"%s\n" , pos->sym.name); }return ret;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 172/244 net: lapbether: Prevent racing when checking whether the netif is running
In reply to Greg Kroah-HartmanFrom: Xie He <[email protected]>
[ Upstream commit 5acd0cfbfbb5a688da1bfb1a2152b0c855115a35 ]
There are two "netif_running" checks in this driver. One is in "lapbeth_xmit" and the other is in "lapbeth_rcv". They serve to make sure that the LAPB APIs called in these functions are called before "lapb_unregister" is called by the "ndo_stop" function.
However, these "netif_running" checks are unreliable, because it's possible that immediately after "netif_running" returns true, "ndo_stop" is called (which causes "lapb_unregister" to be called).
This patch adds locking to make sure "lapbeth_xmit" and "lapbeth_rcv" can reliably check and ensure the netif is running while doing their work.
--- drivers/net/wan/lapbether.c | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-)
drivers/net/wan/lapbether.c +25 -7
@@ -51,6 +51,8 @@ struct lapbethdev {struct list_head node;struct net_device *ethdev;/* link to ethernet device */ struct net_device *axdev;/* lapbeth device (lapb#) */ +bool up; +spinlock_t up_lock;/* Protects "up" */ };static LIST_HEAD (lapbeth_devices);
@@ -98,8 +100,9 @@ static int lapbeth_rcv(struct sk_buff *skb, struct net_device *dev, struct packercu_read_lock (); lapbeth =lapbeth_get_x25_dev (dev);if (!lapbeth) - goto drop_unlock; -if (!netif_running (lapbeth->axdev)) + goto drop_unlock_rcu; +spin_lock_bh (&lapbeth->up_lock); +if (!lapbeth->up) goto drop_unlock; len = skb->data[0 ] + skb->data[1 ] *256 ;
@@ -114,11 +117,14 @@ static int lapbeth_rcv(struct sk_buff *skb, struct net_device *dev, struct packe goto drop_unlock; } out: +spin_unlock_bh (&lapbeth->up_lock);rcu_read_unlock ();return 0 ; drop_unlock:kfree_skb (skb); goto out; +drop_unlock_rcu: +rcu_read_unlock (); drop:kfree_skb (skb);return 0 ;
@@ -148,13 +154,11 @@ static int lapbeth_data_indication(struct net_device *dev, struct sk_buff *skb)static netdev_tx_t lapbeth_xmit (struct sk_buff *skb,struct net_device *dev) { +struct lapbethdev *lapbeth =netdev_priv (dev);int err; -/* -* Just to be *really* sure not to send anything if the interface -* is down, the ethernet device may have gone. -*/ -if (!netif_running (dev)) +spin_lock_bh (&lapbeth->up_lock); +if (!lapbeth->up) goto drop;/* There should be a pseudo header of 1 byte added by upper layers.
@@ -185,6 +189,7 @@ static netdev_tx_t lapbeth_xmit(struct sk_buff *skb, goto drop; } out: +spin_unlock_bh (&lapbeth->up_lock);return NETDEV_TX_OK ; drop:kfree_skb (skb);
@@ -276,6 +281,7 @@ static const struct lapb_register_struct lapbeth_callbacks = {*/ static int lapbeth_open (struct net_device *dev) { +struct lapbethdev *lapbeth =netdev_priv (dev);int err;if ((err =lapb_register (dev, &lapbeth_callbacks)) !=LAPB_OK ) {
@@ -283,13 +289,22 @@ static int lapbeth_open(struct net_device *dev)return -ENODEV ; } +spin_lock_bh (&lapbeth->up_lock); + lapbeth->up = true; +spin_unlock_bh (&lapbeth->up_lock); +return 0 ; }static int lapbeth_close (struct net_device *dev) { +struct lapbethdev *lapbeth =netdev_priv (dev);int err; +spin_lock_bh (&lapbeth->up_lock); + lapbeth->up = false; +spin_unlock_bh (&lapbeth->up_lock); +if ((err =lapb_unregister (dev)) !=LAPB_OK )pr_err ("lapb_unregister error: %d\n" , err);
@@ -347,6 +362,9 @@ static int lapbeth_new_device(struct net_device *dev)dev_hold (dev); lapbeth->ethdev = dev; + lapbeth->up = false; +spin_lock_init (&lapbeth->up_lock); + rc = -EIO ;if (register_netdevice (ndev)) goto fail;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 173/244 powerpc/fadump: Mark fadump_calculate_reserve_size as __init
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
[ Upstream commit fbced1546eaaab57a32e56c974ea8acf10c6abd8 ]
If fadump_calculate_reserve_size() is not inlined, there is a modpost warning:
WARNING: modpost: vmlinux.o(.text+0x5196c): Section mismatch in reference from the function fadump_calculate_reserve_size() to the function .init.text:parse_crashkernel()
The function fadump_calculate_reserve_size() references the function __init parse_crashkernel().
This is often because fadump_calculate_reserve_size lacks a __init annotation or the annotation of parse_crashkernel is wrong.
fadump_calculate_reserve_size() calls parse_crashkernel(), which is marked as __init and fadump_calculate_reserve_size() is called from within fadump_reserve_mem(), which is also marked as __init.
Mark fadump_calculate_reserve_size() as __init to fix the section mismatch. Additionally, remove the inline keyword as it is not necessary to inline this function; the compiler is still free to do so if it feels it is worthwhile since commit 889b3c1245de ("compiler: remove CONFIG_OPTIMIZE_INLINING entirely").
--- arch/powerpc/kernel/fadump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/fadump.c +1 -1
@@ -279,7 +279,7 @@ static void fadump_show_config(void)* that is required for a kernel to boot successfully. * */ -static inline u64 fadump_calculate_reserve_size (void ) +static __init u64 fadump_calculate_reserve_size (void ) {u64 base, size, bootmem_min;int ret;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 174/244 powerpc/prom: Mark identical_pvr_fixup as __init
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
[ Upstream commit 1ef1dd9c7ed27b080445e1576e8a05957e0e4dfc ]
If identical_pvr_fixup() is not inlined, there are two modpost warnings:
WARNING: modpost: vmlinux.o(.text+0x54e8): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:of_get_flat_dt_prop()
The function identical_pvr_fixup() references
the function __init of_get_flat_dt_prop().
This is often because identical_pvr_fixup lacks a __init annotation or the annotation of of_get_flat_dt_prop is wrong.
WARNING: modpost: vmlinux.o(.text+0x551c): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:identify_cpu()
The function identical_pvr_fixup() references
the function __init identify_cpu().
This is often because identical_pvr_fixup lacks a __init annotation or the annotation of identify_cpu is wrong.
identical_pvr_fixup() calls two functions marked as __init and is only called by a function marked as __init so it should be marked as __init as well. At the same time, remove the inline keywork as it is not necessary to inline this function. The compiler is still free to do so if it feels it is worthwhile since commit 889b3c1245de ("compiler:
remove CONFIG_OPTIMIZE_INLINING entirely").
--- arch/powerpc/kernel/prom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/prom.c +1 -1
@@ -266,7 +266,7 @@ static struct feature_property { };#if defined(CONFIG_44x) && defined(CONFIG_PPC_FPU ) -static inline void identical_pvr_fixup (unsigned long node) +static __init void identical_pvr_fixup (unsigned long node) {unsigned int pvr;const char *model =of_get_flat_dt_prop (node,"model" ,NULL );
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 175/244 inet: use bigger hash table for IP ID generation
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit aa6dd211e4b1dde9d5dc25d699d35f789ae7eeba ]
In commit 73f156a6e8c1 ("inetpeer: get rid of ip_id_count") I used a very small hash table that could be abused by patient attackers to reveal sensitive information.
Switch to a dynamic sizing, depending on RAM size.
Typical big hosts will now use 128x more storage (2 MB) to get a similar increase in security and reduction of hash collisions.
As a bonus, use of alloc_large_system_hash() spreads allocated memory among all NUMA nodes.
--- net/ipv4/route.c | 42 ++++++++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 14 deletions(-)
net/ipv4/route.c +28 -14
@@ -66,6 +66,7 @@#include <linux/types.h> #include <linux/kernel.h> #include <linux/mm.h> +#include <linux/memblock.h> #include <linux/string.h> #include <linux/socket.h> #include <linux/sockios.h>
@@ -476,8 +477,10 @@ static void ipv4_confirm_neigh(const struct dst_entry *dst, const void *daddr)__ipv4_confirm_neigh (dev, *(__force u32 *)pkey); } -#define IP_IDENTS_SZ 2048u - +/* Hash tables of size 2048..262144 depending on RAM size. +* Each bucket uses 8 bytes. +*/ +static u32 ip_idents_mask__read_mostly ;static atomic_t *ip_idents__read_mostly ;static u32 *ip_tstamps__read_mostly ;
@@ -487,12 +490,16 @@ static u32 *ip_tstamps __read_mostly;*/ u32 ip_idents_reserve (u32 hash,int segs) { -u32 *p_tstamp = ip_tstamps + hash %IP_IDENTS_SZ ; -atomic_t *p_id = ip_idents + hash %IP_IDENTS_SZ ; -u32 old =READ_ONCE (*p_tstamp); -u32 now = (u32 )jiffies; +u32 bucket, old, now = (u32 )jiffies; +atomic_t *p_id; +u32 *p_tstamp;u32 delta =0 ; + bucket = hash & ip_idents_mask; + p_tstamp = ip_tstamps + bucket; + p_id = ip_idents + bucket; + old =READ_ONCE (*p_tstamp); +if (old != now &&cmpxchg (p_tstamp, old, now) == old) delta =prandom_u32_max (now - old);
@@ -3459,18 +3466,25 @@ struct ip_rt_acct __percpu *ip_rt_acct __read_mostly;int __init ip_rt_init (void ) { +void *idents_hash;int cpu; - ip_idents =kmalloc_array (IP_IDENTS_SZ ,sizeof (*ip_idents), -GFP_KERNEL ); -if (!ip_idents) -panic ("IP: failed to allocate ip_idents\n" ); +/* For modern hosts, this will use 2 MB of memory */ + idents_hash =alloc_large_system_hash ("IP idents" , +sizeof (*ip_idents) +sizeof (*ip_tstamps), +0 , +16 ,/* one bucket per 64 KB */ +HASH_ZERO , +NULL , + &ip_idents_mask, +2048 , +256 *1024 ); + + ip_idents = idents_hash; -prandom_bytes (ip_idents,IP_IDENTS_SZ *sizeof (*ip_idents)); +prandom_bytes (ip_idents, (ip_idents_mask +1 ) *sizeof (*ip_idents)); - ip_tstamps =kcalloc (IP_IDENTS_SZ ,sizeof (*ip_tstamps),GFP_KERNEL ); -if (!ip_tstamps) -panic ("IP: failed to allocate ip_tstamps\n" ); + ip_tstamps = idents_hash + (ip_idents_mask +1 ) *sizeof (*ip_idents);for_each_possible_cpu (cpu) {struct uncached_list *ul = &per_cpu (rt_uncached_list, cpu);
Signature · 1 line
2.30.2
A message that is not in the archive (sent off-list or not yet received): CANEQ_++O0XVVdvynGtf37YCHSBT8CYHnUkK+VsFkOTqeqwOUtA@mail.gmail.com
Greg Kroah-Hartman
maintainerRe: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
Quoted 6 lines · Amit Klein
Hi Greg et al.
I see that you backported this patch (increasing the IP ID hash table size) to the newer LTS branches more than a month ago. But I don't see that it was backported to older LTS branches (4.19, 4.14, 4.9, 4.4). Is this intentional?
It applies cleanly to 4.19, but not the older ones. If you think it is needed there for those kernels, please provide a working backport that we can apply.
thanks,
greg k-h
Re: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
Here is the patch (minus headers, description, etc. - I believe these can be copied as is from the 5.x patch, but not sure about the rules...). It can be applied to 4.14.236. If this is OK, I can move on to 4.9 and 4.4.
net/ipv4/route.c | 41 ++++++++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 13 deletions(-)
net/ipv4/route.c +1 -0
@@ -70,6 +70,7 @@#include <linux/types.h> #include <linux/kernel.h> #include <linux/mm.h> +#include <linux/memblock.h> #include <linux/string.h> #include <linux/socket.h> #include <linux/sockios.h>
@@ -485,8 +486,10 @@ static void ipv4_confirm_neigh(const struct
dst_entry *dst, const void *daddr)
__ipv4_confirm_neigh(dev, *(__force u32 *)pkey);
}
-#define IP_IDENTS_SZ 2048u
-
+/* Hash tables of size 2048..262144 depending on RAM size.
+ * Each bucket uses 8 bytes.
+ */
+static u32 ip_idents_mask __read_mostly;
static atomic_t *ip_idents __read_mostly;
static u32 *ip_tstamps __read_mostly;
@@ -496,12 +499,16 @@ static u32 *ip_tstamps __read_mostly;
*/
u32 ip_idents_reserve(u32 hash, int segs)
{
- u32 *p_tstamp = ip_tstamps + hash % IP_IDENTS_SZ;
- atomic_t *p_id = ip_idents + hash % IP_IDENTS_SZ;
- u32 old = ACCESS_ONCE(*p_tstamp);
- u32 now = (u32)jiffies;
+ u32 bucket, old, now = (u32)jiffies;
+ atomic_t *p_id;
+ u32 *p_tstamp;
u32 delta = 0;+ bucket = hash & ip_idents_mask;
+ p_tstamp = ip_tstamps + bucket;
+ p_id = ip_idents + bucket;
+ old = READ_ONCE(*p_tstamp);
+
if (old != now && cmpxchg(p_tstamp, old, now) == old)
delta = prandom_u32_max(now - old);@@ -3099,17 +3106,25 @@ struct ip_rt_acct __percpu *ip_rt_acct __read_mostly;
int __init ip_rt_init(void)
{
int rc = 0;
+ void *idents_hash;
int cpu;- ip_idents = kmalloc(IP_IDENTS_SZ * sizeof(*ip_idents), GFP_KERNEL);
- if (!ip_idents)
- panic("IP: failed to allocate ip_idents\n");
+ /* For modern hosts, this will use 2 MB of memory */
+ idents_hash = alloc_large_system_hash("IP idents",
+ sizeof(*ip_idents) + sizeof(*ip_tstamps), + 0, + 16, /* one bucket per 64 KB */ + HASH_ZERO, + NULL, + &ip_idents_mask, + 2048, + 256*1024);
+
+ ip_idents = idents_hash;
- prandom_bytes(ip_idents, IP_IDENTS_SZ * sizeof(*ip_idents));
+ prandom_bytes(ip_idents, (ip_idents_mask + 1) * sizeof(*ip_idents));
- ip_tstamps = kcalloc(IP_IDENTS_SZ, sizeof(*ip_tstamps), GFP_KERNEL);
- if (!ip_tstamps)
- panic("IP: failed to allocate ip_tstamps\n");
+ ip_tstamps = idents_hash + (ip_idents_mask + 1) * sizeof(*ip_idents);
for_each_possible_cpu(cpu) {
struct uncached_list *ul = &per_cpu(rt_uncached_list, cpu);Quoted 16 lines · Greg Kroah-Hartman
Quoted 6 lines · Amit Klein
Hi Greg et al.
I see that you backported this patch (increasing the IP ID hash table size) to the newer LTS branches more than a month ago. But I don't see that it was backported to older LTS branches (4.19, 4.14, 4.9, 4.4). Is this intentional?
It applies cleanly to 4.19, but not the older ones. If you think it is needed there for those kernels, please provide a working backport that we can apply.
thanks,
greg k-h
Greg Kroah-Hartman
maintainerRe: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
Quoted 4 lines · Amit Klein
Here is the patch (minus headers, description, etc. - I believe these can be copied as is from the 5.x patch, but not sure about the rules...). It can be applied to 4.14.236. If this is OK, I can move on to 4.9 and 4.4.
I do not know "the patch" is here.
Please resend it in a format that I can apply it in. Look at the stable list archives for lots of examples of backported patches, they need to have the original changelog description as well as the git commit id of the patch you are backporting, which I do not see here at all.
thanks,
greg k-h
Greg Kroah-Hartman
maintainerRe: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
Quoted 6 lines · Greg Kroah-Hartman
Quoted 4 lines · Amit Klein
Here is the patch (minus headers, description, etc. - I believe these can be copied as is from the 5.x patch, but not sure about the rules...). It can be applied to 4.14.236. If this is OK, I can move on to 4.9 and 4.4.
Quoted 6 lines
I do not know "the patch" is here.
Please resend it in a format that I can apply it in. Look at the stable list archives for lots of examples of backported patches, they need to have the original changelog description as well as the git commit id of the patch you are backporting, which I do not see here at all.
Also, did you test this on 4.14.y and prove that it is both needed, and works properly?
thanks,
greg k-h
RE: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
In reply to Amit KleinFrom: Amit Klein
Quoted 1 line
Sent: 16 June 2021 10:17
...
Quoted 6 lines
(quoted diff) +4
-2-#define IP_IDENTS_SZ 2048u - +/* Hash tables of size 2048..262144 depending on RAM size. + * Each bucket uses 8 bytes. + */ +static u32 ip_idents_mask __read_mostly;
...
Review
Quoted 11 lines
(quoted diff) +11
-0+ /* For modern hosts, this will use 2 MB of memory */ + idents_hash = alloc_large_system_hash("IP idents", + sizeof(*ip_idents) + sizeof(*ip_tstamps), + 0, + 16, /* one bucket per 64 KB */ + HASH_ZERO, + NULL, + &ip_idents_mask, + 2048, + 256*1024); +
Can someone explain why this is a good idea for a 'normal' system?
Why should my desktop system 'waste' 2MB of memory on a massive hash table that I don't need.
It might be needed by systems than handle massive numbers of concurrent connections - but that isn't 'most systems'.
Surely it would be better to detect when the number of entries is comparable to the table size and then resize the table.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Greg Kroah-Hartman
maintainerRe: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
Quoted 24 lines · David Laight
From: Amit Klein
Quoted 1 line
Sent: 16 June 2021 10:17
...
Quoted 6 lines
(quoted diff) +4
-2-#define IP_IDENTS_SZ 2048u - +/* Hash tables of size 2048..262144 depending on RAM size. + * Each bucket uses 8 bytes. + */ +static u32 ip_idents_mask __read_mostly;...
Review
Quoted 11 lines
(quoted diff) +11
-0+ /* For modern hosts, this will use 2 MB of memory */ + idents_hash = alloc_large_system_hash("IP idents", + sizeof(*ip_idents) + sizeof(*ip_tstamps), + 0, + 16, /* one bucket per 64 KB */ + HASH_ZERO, + NULL, + &ip_idents_mask, + 2048, + 256*1024); +Can someone explain why this is a good idea for a 'normal' system?
Quoted 7 lines
Why should my desktop system 'waste' 2MB of memory on a massive hash table that I don't need.
It might be needed by systems than handle massive numbers of concurrent connections - but that isn't 'most systems'.Surely it would be better to detect when the number of entries is comparable to the table size and then resize the table.
Patches always gladly accepted.
Re: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
In reply to David LaightQuoted 23 lines · David Laight
From: Amit Klein
Quoted 1 line
Sent: 16 June 2021 10:17
...
Quoted 6 lines
(quoted diff) +4
-2-#define IP_IDENTS_SZ 2048u - +/* Hash tables of size 2048..262144 depending on RAM size. + * Each bucket uses 8 bytes. + */ +static u32 ip_idents_mask __read_mostly;...
Review
Quoted 11 lines
(quoted diff) +11
-0+ /* For modern hosts, this will use 2 MB of memory */ + idents_hash = alloc_large_system_hash("IP idents", + sizeof(*ip_idents) + sizeof(*ip_tstamps), + 0, + 16, /* one bucket per 64 KB */ + HASH_ZERO, + NULL, + &ip_idents_mask, + 2048, + 256*1024); +
Quoted 4 lines
Can someone explain why this is a good idea for a 'normal' system?
Why should my desktop system 'waste' 2MB of memory on a massive hash table that I don't need.
Only if your desktop has a lot of RAM.
Otherwise the table will be smaller (like it was before this patch)
Quoted 5 lines
It might be needed by systems than handle massive numbers of concurrent connections - but that isn't 'most systems'.
Surely it would be better to detect when the number of entries is comparable to the table size and then resize the table.
Please send a patch, instead of always complaining about what others do.
Security comes first.
Then eventually we can ' optimize' .
Quoted 6 lines
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
In reply to David LaightQuoted 3 lines · David Laight
Can someone explain why this is a good idea for a 'normal' system?
This patch mitigates some techniques that leak internal state due to table hash collisions.
Quoted 2 lines
Why should my desktop system 'waste' 2MB of memory on a massive hash table that I don't need.
In the patch's defense, it only consumes 2MB when the physical RAM is >= 16GB.
Quoted 5 lines
It might be needed by systems than handle massive numbers of concurrent connections - but that isn't 'most systems'.
Surely it would be better to detect when the number of entries is comparable to the table size and then resize the table.
Security-wise, this approach is not effective. The table size was increased to reduce the likelihood of hash collisions. These start happening when you have ~N^(1/2) elements (for table size N), so you'll need to resize pretty quickly anyway.
RE: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
From: Amit Klein
Quoted 8 lines
Sent: 16 June 2021 14:20
Quoted 1 line · David Laight
Can someone explain why this is a good idea for a 'normal' system?
This patch mitigates some techniques that leak internal state due to table hash collisions.
As you say below it isn't really effective...
Quoted 4 lines
Quoted 2 lines
Why should my desktop system 'waste' 2MB of memory on a massive hash table that I don't need.
In the patch's defense, it only consumes 2MB when the physical RAM is >= 16GB.
Right, but I've 16GB of memory because I run some very large applications that need all the memory they can get (and more).
In any case, for many architectures 8GB is 'entry level'. That includes some or the 'small' ARM cpus.
They are unlikely to have tens of connections, never mind thousands.
Quoted 10 lines
Quoted 5 lines
It might be needed by systems than handle massive numbers of concurrent connections - but that isn't 'most systems'.
Surely it would be better to detect when the number of entries is comparable to the table size and then resize the table.
Security-wise, this approach is not effective. The table size was increased to reduce the likelihood of hash collisions. These start happening when you have ~N^(1/2) elements (for table size N), so you'll need to resize pretty quickly anyway.
You really have to live with some hash collisions.
Resizing at N^(1/2) just doesn't scale.
Not only that the hash function will stop generating non-colliding values once the table starts getting big.
(A very expensive hash function might help - but i wouldn't count on it.)
In any case, the chance of hitting a hash collision is slightly less than (table_size / active_entries).
What you want to avoid is the ELF symbol hash when the average chain length is about 1.5 and you have to separately check the hash table of every shared library.
That quickly balloons to a lot of string compares.
(I looked at that for mozilla may years ago - was horrid.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
Quoted 4 lines · David Laight
Quoted 2 lines
This patch mitigates some techniques that leak internal state due to table hash collisions.
As you say below it isn't really effective...
Actually it's Amit's attack which is really effective against anything that is not 100% random. And as you mentioned yourself in another thread, full randomness is not desirable as it can result in big trouble with ID collisions, especially when limited to 16 bits only. The only remaining factor to act on is thus the number of buckets to reduce the effectiveness of the attack.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Why should my desktop system 'waste' 2MB of memory on a massive hash table that I don't need.
In the patch's defense, it only consumes 2MB when the physical RAM is >= 16GB.
Right, but I've 16GB of memory because I run some very large applications that need all the memory they can get (and more).
Then by all means if your system is so tightly sized, buy this extra 2 MB DRAM stick you're missing, and install it next to your existing 16GB one.
Quoted 6 lines
Quoted 4 lines
Security-wise, this approach is not effective. The table size was increased to reduce the likelihood of hash collisions. These start happening when you have ~N^(1/2) elements (for table size N), so you'll need to resize pretty quickly anyway.
You really have to live with some hash collisions.
Absolutely, and that's the principle, that at some point it costs enough to the attacker for the attack to not be affordable or at least be easily detectable. All this for 1/8192 of your total RAM in the worst case, you will not notice more than when some fields are added to certain important structures and probably much less than when you simply upgrade whatever lib or binary. And probably that you forgot to reduce the amount of RAM dedicated to the video in your BIOS and can salvage no less than 32MB there!
Willy
Greg Kroah-Hartman
maintainerRe: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
In reply to Amit KleinQuoted 36 lines · Amit Klein
Here is the patch (minus headers, description, etc. - I believe these can be copied as is from the 5.x patch, but not sure about the rules...). It can be applied to 4.14.236. If this is OK, I can move on to 4.9 and 4.4.
net/ipv4/route.c | 41 ++++++++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 13 deletions(-)net/ipv4/route.c +5
-2@@ -70,6 +70,7 @@#include <linux/types.h> #include <linux/kernel.h> #include <linux/mm.h> +#include <linux/memblock.h> #include <linux/string.h> #include <linux/socket.h> #include <linux/sockios.h> @@ -485,8 +486,10 @@ static void ipv4_confirm_neigh(const struct dst_entry *dst, const void *daddr) __ipv4_confirm_neigh(dev, *(__force u32 *)pkey); } -#define IP_IDENTS_SZ 2048u - +/* Hash tables of size 2048..262144 depending on RAM size. +* Each bucket uses 8 bytes. +*/ +static u32 ip_idents_mask__read_mostly ;static atomic_t *ip_idents__read_mostly ;static u32 *ip_tstamps__read_mostly ;
net/ipv4/route.c static u32 *ip_tstamps __read_mostly; · line 504
Quoted 10 lines
net/ipv4/route.c +3
-4@@ -496,12 +499,16 @@ static u32 *ip_tstamps __read_mostly;*/ u32 ip_idents_reserve (u32 hash,int segs) { -u32 *p_tstamp = ip_tstamps + hash %IP_IDENTS_SZ ; -atomic_t *p_id = ip_idents + hash %IP_IDENTS_SZ ; -u32 old =ACCESS_ONCE (*p_tstamp); -u32 now = (u32 )jiffies; +u32 bucket, old, now = (u32 )jiffies; +atomic_t *p_id; +u32 *p_tstamp;
Your patch is corrupted and couldn't be applied if I wanted to :(
Re: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
I just submitted a revised patch for 4.14. Sorry for the earlier blunder.
Quoted 51 lines · Greg Kroah-Hartman
Quoted 36 lines · Amit Klein
Here is the patch (minus headers, description, etc. - I believe these can be copied as is from the 5.x patch, but not sure about the rules...). It can be applied to 4.14.236. If this is OK, I can move on to 4.9 and 4.4.
net/ipv4/route.c | 41 ++++++++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 13 deletions(-)net/ipv4/route.c +5
-2@@ -70,6 +70,7 @@#include <linux/types.h> #include <linux/kernel.h> #include <linux/mm.h> +#include <linux/memblock.h> #include <linux/string.h> #include <linux/socket.h> #include <linux/sockios.h> @@ -485,8 +486,10 @@ static void ipv4_confirm_neigh(const struct dst_entry *dst, const void *daddr) __ipv4_confirm_neigh(dev, *(__force u32 *)pkey); } -#define IP_IDENTS_SZ 2048u - +/* Hash tables of size 2048..262144 depending on RAM size. +* Each bucket uses 8 bytes. +*/ +static u32 ip_idents_mask__read_mostly ;static atomic_t *ip_idents__read_mostly ;static u32 *ip_tstamps__read_mostly ;net/ipv4/route.c static u32 *ip_tstamps __read_mostly; · line 504
Quoted 10 lines
net/ipv4/route.c +3
-4@@ -496,12 +499,16 @@ static u32 *ip_tstamps __read_mostly;*/ u32 ip_idents_reserve (u32 hash,int segs) { -u32 *p_tstamp = ip_tstamps + hash %IP_IDENTS_SZ ; -atomic_t *p_id = ip_idents + hash %IP_IDENTS_SZ ; -u32 old =ACCESS_ONCE (*p_tstamp); -u32 now = (u32 )jiffies; +u32 bucket, old, now = (u32 )jiffies; +atomic_t *p_id; +u32 *p_tstamp;Your patch is corrupted and couldn't be applied if I wanted to :(
Greg Kroah-Hartman
maintainerRe: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
In reply to Greg Kroah-HartmanQuoted 11 lines · Greg Kroah-Hartman
Quoted 6 lines · Amit Klein
Hi Greg et al.
I see that you backported this patch (increasing the IP ID hash table size) to the newer LTS branches more than a month ago. But I don't see that it was backported to older LTS branches (4.19, 4.14, 4.9, 4.4). Is this intentional?
It applies cleanly to 4.19, but not the older ones. If you think it is needed there for those kernels, please provide a working backport that we can apply.
It breaks the build on 4.19, which is why I didn't apply it there, so I would need a working version for that tree as well.
thanks,
greg k-h
Re: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation
I just sent a revised patch for 4.19.
Quoted 20 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman
Quoted 6 lines · Amit Klein
Hi Greg et al.
I see that you backported this patch (increasing the IP ID hash table size) to the newer LTS branches more than a month ago. But I don't see that it was backported to older LTS branches (4.19, 4.14, 4.9, 4.4). Is this intentional?
It applies cleanly to 4.19, but not the older ones. If you think it is needed there for those kernels, please provide a working backport that we can apply.
It breaks the build on 4.19, which is why I didn't apply it there, so I would need a working version for that tree as well.
thanks,
greg k-h
Greg Kroah-Hartman
maintainerPATCH 176/244 powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration
In reply to Greg Kroah-HartmanFrom: Chen Huang <[email protected]>
[ Upstream commit 4fe529449d85e78972fa327999961ecc83a0b6db ]
When compiling the powerpc with the SMP disabled, it shows the issue:
arch/powerpc/kernel/watchdog.c: In function ‘watchdog_smp_panic’:arch/powerpc/kernel/watchdog.c:177:4: error: implicit declaration of function ‘smp_send_nmi_ipi’; did you mean ‘smp_send_stop’? [-Werror=implicit-function-declaration]
177 | smp_send_nmi_ipi(c, wd_lockup_ipi, 1000000);
| ^~~~~~~~~~~~~~~~
| smp_send_stopcc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:273: arch/powerpc/kernel/watchdog.o] Error 1 make[1]: *** [scripts/Makefile.build:534: arch/powerpc/kernel] Error 2
make: *** [Makefile:1980: arch/powerpc] Error 2
make: *** Waiting for unfinished jobs....
We found that powerpc used ipi to implement hardlockup watchdog, so the HAVE_HARDLOCKUP_DETECTOR_ARCH should depend on the SMP.
--- arch/powerpc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/Kconfig +1 -1
@@ -214,7 +214,7 @@ config PPC select HAVE_MEMBLOCK_NODE_MAP select HAVE_MOD_ARCH_SPECIFIC select HAVE_NMI if PERF_EVENTS || (PPC64 && PPC_BOOK3S) - select HAVE_HARDLOCKUP_DETECTOR_ARCH if (PPC64 && PPC_BOOK3S) + select HAVE_HARDLOCKUP_DETECTOR_ARCH if PPC64 && PPC_BOOK3S && SMP select HAVE_OPROFILE select HAVE_OPTPROBES if PPC64 select HAVE_PERF_EVENTS
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 177/244 ALSA: core: remove redundant spin_lock pair in snd_card_disconnect
In reply to Greg Kroah-HartmanFrom: Jia Zhou <[email protected]>
[ Upstream commit abc21649b3e5c34b143bf86f0c78e33d5815e250 ]
modification in commit 2a3f7221acdd ("ALSA: core: Fix card races between register and disconnect") resulting in this problem.
--- sound/core/init.c | 2 -- 1 file changed, 2 deletions(-)
sound/core/init.c +0 -2
@@ -384,10 +384,8 @@ int snd_card_disconnect(struct snd_card *card)return 0 ; } card->shutdown =1 ; -spin_unlock (&card->files_lock);/* replace file->f_op with special dummy operations */ -spin_lock (&card->files_lock);list_for_each_entry (mfile, &card->files_list, list) {/* it's critical part, use endless loop */ /* we have no room to fail */
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 178/244 bug: Remove redundant condition check in report_bug
In reply to Greg Kroah-HartmanFrom: Andrew Scull <[email protected]>
[ Upstream commit 3ad1a6cb0abc63d036fc866bd7c2c5983516dec5 ]
report_bug() will return early if it cannot find a bug corresponding to the provided address. The subsequent test for the bug will always be true so remove it.
--- lib/bug.c | 33 +++++++++++++++------------------ 1 file changed, 15 insertions(+), 18 deletions(-)
lib/bug.c +15 -18
@@ -155,30 +155,27 @@ enum bug_trap_type report_bug(unsigned long bugaddr, struct pt_regs *regs) file =NULL ; line =0 ; - warning =0 ; -if (bug) {#ifdef CONFIG_DEBUG_BUGVERBOSE #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS - file = bug->file; + file = bug->file;#else - file = (const char *)bug + bug->file_disp; + file = (const char *)bug + bug->file_disp;#endif - line = bug->line; + line = bug->line;#endif - warning = (bug->flags &BUGFLAG_WARNING ) !=0 ; - once = (bug->flags &BUGFLAG_ONCE ) !=0 ; - done = (bug->flags &BUGFLAG_DONE ) !=0 ; - -if (warning && once) { -if (done) -return BUG_TRAP_TYPE_WARN ; - -/* -* Since this is the only store, concurrency is not an issue. -*/ - bug->flags |=BUGFLAG_DONE ; - } + warning = (bug->flags &BUGFLAG_WARNING ) !=0 ; + once = (bug->flags &BUGFLAG_ONCE ) !=0 ; + done = (bug->flags &BUGFLAG_DONE ) !=0 ; + +if (warning && once) { +if (done) +return BUG_TRAP_TYPE_WARN ; + +/* +* Since this is the only store, concurrency is not an issue. +*/ + bug->flags |=BUGFLAG_DONE ; }/*
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 179/244 nfc: pn533: prevent potential memory corruption
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit ca4d4c34ae9aa5c3c0da76662c5e549d2fc0cc86 ]
If the "type_a->nfcid_len" is too large then it would lead to memory corruption in pn533_target_found_type_a() when we do:
memcpy(nfc_tgt->nfcid1, tgt_type_a->nfcid_data, nfc_tgt->nfcid1_len);
--- drivers/nfc/pn533/pn533.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/nfc/pn533/pn533.c +3 -0
@@ -680,6 +680,9 @@ static bool pn533_target_type_a_is_valid(struct pn533_target_type_a *type_a,if (PN533_TYPE_A_SEL_CASCADE (type_a->sel_res) !=0 )return false; +if (type_a->nfcid_len >NFC_NFCID1_MAXSIZE ) +return false; +return true; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 180/244 net: hns3: Limiting the scope of vector_ring_chain variable
In reply to Greg Kroah-HartmanFrom: Salil Mehta <[email protected]>
[ Upstream commit d392ecd1bc29ae15b0e284d5f732c2d36f244271 ]
Limiting the scope of the variable vector_ring_chain to the block where it is used.
--- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +2 -1
@@ -3322,7 +3322,6 @@ static void hns3_nic_set_cpumask(struct hns3_nic_priv *priv)static int hns3_nic_init_vector_data (struct hns3_nic_priv *priv) { -struct hnae3_ring_chain_node vector_ring_chain;struct hnae3_handle *h = priv->ae_handle;struct hns3_enet_tqp_vector *tqp_vector;int ret =0 ;
@@ -3354,6 +3353,8 @@ static int hns3_nic_init_vector_data(struct hns3_nic_priv *priv) }for (i =0 ; i < priv->vector_num; i++) { +struct hnae3_ring_chain_node vector_ring_chain; + tqp_vector = &priv->tqp_vector[i]; tqp_vector->rx_group.total_bytes =0 ;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 181/244 mips: bmips: fix syscon-reboot nodes
In reply to Greg Kroah-HartmanFrom: Álvaro Fernández Rojas <[email protected]>
[ Upstream commit cde58b861a1d365568588adda59d42351c0c4ad3 ]
Commit a23c4134955e added the clock controller nodes, incorrectly changing the syscon-reboot nodes addresses.
--- arch/mips/boot/dts/brcm/bcm3368.dtsi | 2 +- arch/mips/boot/dts/brcm/bcm63268.dtsi | 2 +- arch/mips/boot/dts/brcm/bcm6358.dtsi | 2 +- arch/mips/boot/dts/brcm/bcm6362.dtsi | 2 +- arch/mips/boot/dts/brcm/bcm6368.dtsi | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-)
arch/mips/boot/dts/brcm/bcm3368.dtsi +1 -1
@@ -59,7 +59,7 @@ periph_cntl: syscon@fff8c008 { compatible = "syscon"; - reg = <0xfff8c000 0x4>; + reg = <0xfff8c008 0x4>; native-endian; };
arch/mips/boot/dts/brcm/bcm63268.dtsi +1 -1
@@ -59,7 +59,7 @@ periph_cntl: syscon@10000008 { compatible = "syscon"; - reg = <0x10000000 0xc>; + reg = <0x10000008 0x4>; native-endian; };
arch/mips/boot/dts/brcm/bcm6358.dtsi +1 -1
@@ -59,7 +59,7 @@ periph_cntl: syscon@fffe0008 { compatible = "syscon"; - reg = <0xfffe0000 0x4>; + reg = <0xfffe0008 0x4>; native-endian; };
arch/mips/boot/dts/brcm/bcm6362.dtsi +1 -1
@@ -59,7 +59,7 @@ periph_cntl: syscon@10000008 { compatible = "syscon"; - reg = <0x10000000 0xc>; + reg = <0x10000008 0x4>; native-endian; };
arch/mips/boot/dts/brcm/bcm6368.dtsi +1 -1
@@ -59,7 +59,7 @@ periph_cntl: syscon@100000008 { compatible = "syscon"; - reg = <0x10000000 0xc>; + reg = <0x10000008 0x4>; native-endian; };
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 182/244 ALSA: usb-audio: Add error checks for usb_driver_claim_interface() calls
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
[ Upstream commit 5fb45414ae03421255593fd5556aa2d1d82303aa ]
There are a few calls of usb_driver_claim_interface() but all of those miss the proper error checks, as reported by Coverity. This patch adds those missing checks.
Along with it, replace the magic pointer with -1 with a constant USB_AUDIO_IFACE_UNUSED for better readability.
Addresses-Coverity-ID: 1475943 ("Error handling issues")
Addresses-Coverity-ID: 1475944 ("Error handling issues")
Addresses-Coverity-ID: 1475945 ("Error handling issues")
--- sound/usb/card.c | 14 +++++++------- sound/usb/quirks.c | 16 ++++++++++++---- sound/usb/usbaudio.h | 2 ++ 3 files changed, 21 insertions(+), 11 deletions(-)
sound/usb/card.c +7 -7
@@ -176,9 +176,8 @@ static int snd_usb_create_stream(struct snd_usb_audio *chip, int ctrlif, int int ctrlif, interface);return -EINVAL ; } -usb_driver_claim_interface (&usb_audio_driver, iface, (void *)-1L ); - -return 0 ; +return usb_driver_claim_interface (&usb_audio_driver, iface, +USB_AUDIO_IFACE_UNUSED ); } if ((altsd->bInterfaceClass != USB_CLASS_AUDIO &&
@@ -198,7 +197,8 @@ static int snd_usb_create_stream(struct snd_usb_audio *chip, int ctrlif, int intif (!snd_usb_parse_audio_interface (chip, interface)) {usb_set_interface (dev, interface,0 );/* reset the current interface */ -usb_driver_claim_interface (&usb_audio_driver, iface, (void *)-1L ); +return usb_driver_claim_interface (&usb_audio_driver, iface, +USB_AUDIO_IFACE_UNUSED ); }return 0 ;
@@ -703,7 +703,7 @@ static void usb_audio_disconnect(struct usb_interface *intf)struct snd_card *card;struct list_head *p; -if (chip == (void *)-1L ) +if (chip ==USB_AUDIO_IFACE_UNUSED )return ; card = chip->card;
@@ -811,7 +811,7 @@ static int usb_audio_suspend(struct usb_interface *intf, pm_message_t message)struct usb_mixer_interface *mixer;struct list_head *p; -if (chip == (void *)-1L ) +if (chip ==USB_AUDIO_IFACE_UNUSED )return 0 ;if (!chip->num_suspended_intf++) {
@@ -842,7 +842,7 @@ static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)struct list_head *p;int err =0 ; -if (chip == (void *)-1L ) +if (chip ==USB_AUDIO_IFACE_UNUSED )return 0 ;atomic_inc (&chip->active);/* avoid autopm */
sound/usb/quirks.c +12 -4
@@ -55,8 +55,12 @@ static int create_composite_quirk(struct snd_usb_audio *chip,if (!iface)continue ;if (quirk->ifnum != probed_ifnum && - !usb_interface_claimed (iface)) -usb_driver_claim_interface (driver, iface, (void *)-1L ); + !usb_interface_claimed (iface)) { + err =usb_driver_claim_interface (driver, iface, +USB_AUDIO_IFACE_UNUSED ); +if (err <0 ) +return err; + } }return 0 ;
@@ -390,8 +394,12 @@ static int create_autodetect_quirks(struct snd_usb_audio *chip,continue ; err =create_autodetect_quirk (chip, iface, driver); -if (err >=0 ) -usb_driver_claim_interface (driver, iface, (void *)-1L ); +if (err >=0 ) { + err =usb_driver_claim_interface (driver, iface, +USB_AUDIO_IFACE_UNUSED ); +if (err <0 ) +return err; + } }return 0 ;
sound/usb/usbaudio.h +2 -0
@@ -59,6 +59,8 @@ struct snd_usb_audio {struct media_intf_devnode *ctl_intf_media_devnode; }; +#define USB_AUDIO_IFACE_UNUSED ((void *)-1L) + #define usb_audio_err(chip, fmt, args...) \ dev_err(&(chip)->dev->dev, fmt, ##args) #define usb_audio_warn(chip, fmt, args...) \
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 183/244 KVM: arm64: Initialize VCPU mdcr_el2 before loading it
In reply to Greg Kroah-HartmanFrom: Alexandru Elisei <[email protected]>
[ Upstream commit 263d6287da1433aba11c5b4046388f2cdf49675c ]
When a VCPU is created, the kvm_vcpu struct is initialized to zero in kvm_vm_ioctl_create_vcpu(). On VHE systems, the first time vcpu.arch.mdcr_el2 is loaded on hardware is in vcpu_load(), before it is set to a sensible value in kvm_arm_setup_debug() later in the run loop. The result is that KVM executes for a short time with MDCR_EL2 set to zero.
This has several unintended consequences:
* Setting MDCR_EL2.HPMN to 0 is constrained unpredictable according to ARM DDI 0487G.a, page D13-3820. The behavior specified by the architecture in this case is for the PE to behave as if MDCR_EL2.HPMN is set to a value less than or equal to PMCR_EL0.N, which means that an unknown number of counters are now disabled by MDCR_EL2.HPME, which is zero.
* The host configuration for the other debug features controlled by MDCR_EL2 is temporarily lost. This has been harmless so far, as Linux doesn't use the other fields, but that might change in the future.
Let's avoid both issues by initializing the VCPU's mdcr_el2 field in kvm_vcpu_vcpu_first_run_init(), thus making sure that the MDCR_EL2 register has a consistent value after each vcpu_load().
--- arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/kvm/debug.c | 88 +++++++++++++++++++++---------- virt/kvm/arm/arm.c | 2 + 3 files changed, 63 insertions(+), 28 deletions(-)
arch/arm64/include/asm/kvm_host.h +1 -0
@@ -552,6 +552,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}static inline void kvm_arch_vcpu_block_finish (struct kvm_vcpu *vcpu) {}void kvm_arm_init_debug (void ); +void kvm_arm_vcpu_init_debug (struct kvm_vcpu *vcpu);void kvm_arm_setup_debug (struct kvm_vcpu *vcpu);void kvm_arm_clear_debug (struct kvm_vcpu *vcpu);void kvm_arm_reset_debug_ptr (struct kvm_vcpu *vcpu);
arch/arm64/kvm/debug.c +60 -28
131 lines not on this page · raw message
virt/kvm/arm/arm.c +2 -0
@@ -579,6 +579,8 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu) vcpu->arch.has_run_once = true; +kvm_arm_vcpu_init_debug (vcpu); +if (likely (irqchip_in_kernel (kvm))) {/* * Map the VGIC hardware resources before running a vcpu the
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 184/244 ASoC: simple-card: fix possible uninitialized single_cpu local variable
In reply to Greg Kroah-HartmanFrom: Krzysztof Kozlowski <[email protected]>
[ Upstream commit fa74c223b6fd78a5314b4c61b9abdbed3c2185b4 ]
The 'single_cpu' local variable is assigned by asoc_simple_parse_dai() and later used in a asoc_simple_canonicalize_cpu() call, assuming the entire function did not exit on errors.
However the first function returns 0 if passed device_node is NULL, thus leaving the variable uninitialized and reporting success.
Addresses-Coverity: Uninitialized scalar variable
--- sound/soc/generic/audio-graph-card.c | 2 +- sound/soc/generic/simple-card.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
sound/soc/generic/audio-graph-card.c +1 -1
@@ -340,7 +340,7 @@ static int graph_dai_link_of(struct asoc_simple_priv *priv,struct device_node *top = dev->of_node;struct asoc_simple_dai *cpu_dai;struct asoc_simple_dai *codec_dai; -int ret, single_cpu; +int ret, single_cpu =0 ;/* Do it only CPU turn */ if (!li->cpu)
sound/soc/generic/simple-card.c +1 -1
@@ -258,7 +258,7 @@ static int simple_dai_link_of(struct asoc_simple_priv *priv,struct device_node *plat =NULL ;char prop[128 ];char *prefix ="" ; -int ret, single_cpu; +int ret, single_cpu =0 ;/* * |CPU |Codec : turn
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 185/244 liquidio: Fix unintented sign extension of a left shift of a u16
In reply to Greg Kroah-HartmanFrom: Colin Ian King <[email protected]>
[ Upstream commit 298b58f00c0f86868ea717426beb5c1198772f81 ]
The macro CN23XX_PEM_BAR1_INDEX_REG is being used to shift oct->pcie_port (a u16) left 24 places. There are two subtle issues here, first the shift gets promoted to an signed int and then sign extended to a u64. If oct->pcie_port is 0x80 or more then the upper bits get sign extended to 1. Secondly shfiting a u16 24 bits will lead to an overflow so it needs to be cast to a u64 for all the bits to not overflow.
It is entirely possible that the u16 port value is never large enough for this to fail, but it is useful to fix unintended overflows such as this.
Fix this by casting the port parameter to the macro to a u64 before the shift.
Addresses-Coverity: ("Unintended sign extension")
--- drivers/net/ethernet/cavium/liquidio/cn23xx_pf_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_regs.h +1 -1
@@ -521,7 +521,7 @@#define CN23XX_BAR1_INDEX_OFFSET 3#define CN23XX_PEM_BAR1_INDEX_REG (port, idx) \ - (CN23XX_PEM_BAR1_INDEX_START + ((port) << CN23XX_PEM_OFFSET) + \ + (CN23XX_PEM_BAR1_INDEX_START + (((u64)port) << CN23XX_PEM_OFFSET) + \ ((idx) << CN23XX_BAR1_INDEX_OFFSET))/*############################ DPI #########################*/
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 186/244 powerpc/64s: Fix pte update for kernel memory on radix
In reply to Greg Kroah-HartmanFrom: Jordan Niethe <[email protected]>
[ Upstream commit b8b2f37cf632434456182e9002d63cbc4cccc50c ]
When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised.
radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region.
However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults.
As the code patching is done using __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen:
BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1
This results in the kind of issue reported here:
https://lore.kernel.org/linuxppc-dev/[email protected]/
Chris Riedl suggested a reliable way to reproduce the issue:
$ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) &
Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like:
ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------
ftrace failed to modify
[<c000000000bf8e5c>] napi_busy_loop+0xc/0x390
actual: 11:3b:47:4b
Setting ftrace call site to call ftrace function
ftrace record flags: 80000001
(1)
expected tramp: c00000000006c96c
------------[ cut here ]------------
WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8
Modules linked in: nop_module(PO-) [last unloaded: nop_module]
CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1
NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0
REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a)
MSR: 900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28008848 XER: 20040000
CFAR: c0000000001a9c98 IRQMASK: 0
GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022
GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8
GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118
GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000
GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008
GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8
GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020
GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0
NIP ftrace_bug+0x28c/0x2e8
LR ftrace_bug+0x288/0x2e8
Call Trace:
ftrace_bug+0x288/0x2e8 (unreliable)
ftrace_modify_all_code+0x168/0x210
arch_ftrace_update_code+0x18/0x30
ftrace_run_update_code+0x44/0xc0
ftrace_startup+0xf8/0x1c0
register_ftrace_function+0x4c/0xc0
function_trace_init+0x80/0xb0
tracing_set_tracer+0x2a4/0x4f0
tracing_set_trace_write+0xd4/0x130
vfs_write+0xf0/0x330
ksys_write+0x84/0x140
system_call_exception+0x14c/0x230
system_call_common+0xf0/0x27cTo fix this when updating kernel memory PTEs using ptesync.
--- arch/powerpc/include/asm/book3s/64/radix.h | 6 ++++-- arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-)
arch/powerpc/include/asm/book3s/64/radix.h +4 -2
@@ -206,8 +206,10 @@ static inline void radix__set_pte_at(struct mm_struct *mm, unsigned long addr,* from ptesync, it should probably go into update_mmu_cache, rather * than set_pte_at (which is used to set ptes unrelated to faults). * -* Spurious faults to vmalloc region are not tolerated, so there is -* a ptesync in flush_cache_vmap. +* Spurious faults from the kernel memory are not tolerated, so there +* is a ptesync in flush_cache_vmap, and __map_kernel_page() follows +* the pte update sequence from ISA Book III 6.10 Translation Table +* Update Synchronization Requirements. */ }
arch/powerpc/mm/book3s64/radix_pgtable.c +2 -2
@@ -97,7 +97,7 @@ static int early_map_kernel_page(unsigned long ea, unsigned long pa, set_the_pte:set_pte_at (&init_mm, ea, ptep,pfn_pte (pfn, flags)); -smp_wmb (); + asmvolatile ("ptesync" : : :"memory" );return 0 ; }
@@ -155,7 +155,7 @@ static int __map_kernel_page(unsigned long ea, unsigned long pa, set_the_pte:set_pte_at (&init_mm, ea, ptep,pfn_pte (pfn, flags)); -smp_wmb (); + asmvolatile ("ptesync" : : :"memory" );return 0 ; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 187/244 powerpc/perf: Fix PMU constraint check for EBB events
In reply to Greg Kroah-HartmanFrom: Athira Rajeev <[email protected]>
[ Upstream commit 10f8f96179ecc7f69c927f6d231f6d02736cea83 ]
The power PMU group constraints includes check for EBB events to make sure all events in a group must agree on EBB. This will prevent scheduling EBB and non-EBB events together. But in the existing check, settings for constraint mask and value is interchanged. Patch fixes the same.
Before the patch, PMU selftest "cpu_event_pinned_vs_ebb_test" fails with below in dmesg logs. This happens because EBB event gets enabled along with a non-EBB cpu event.
[35600.453346] cpu_event_pinne[41326]: illegal instruction (4) at 10004a18 nip 10004a18 lr 100049f8 code 1 in cpu_event_pinned_vs_ebb_test[10000000+10000]
Test results after the patch:
$ ./pmu/ebb/cpu_event_pinned_vs_ebb_test test: cpu_event_pinned_vs_ebb tags: git_version:v5.12-rc5-93-gf28c3125acd3-dirty Binding to cpu 8 EBB Handler is at 0x100050c8 read error on event 0x7fffe6bd4040! PM_RUN_INST_CMPL: result 9872 running/enabled 37930432 success: cpu_event_pinned_vs_ebb
This bug was hidden by other logic until commit 1908dc911792 (perf:
Tweak perf_event_attr::exclusive semantics).
--- arch/powerpc/perf/isa207-common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/powerpc/perf/isa207-common.c +2 -2
@@ -363,8 +363,8 @@ ebb_bhrb:* EBB events are pinned & exclusive, so this should never actually * hit, but we leave it as a fallback in case. */ - mask |=CNST_EBB_VAL (ebb); - value |=CNST_EBB_MASK ; + mask |=CNST_EBB_MASK ; + value |=CNST_EBB_VAL (ebb); *maskp = mask; *valp = value;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 188/244 powerpc: iommu: fix build when neither PCI or IBMVIO is set
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit b27dadecdf9102838331b9a0b41ffc1cfe288154 ]
When neither CONFIG_PCI nor CONFIG_IBMVIO is set/enabled, iommu.c has a build error. The fault injection code is not useful in that kernel config, so make the FAIL_IOMMU option depend on PCI || IBMVIO.
Prevents this build error (warning escalated to error):../arch/powerpc/kernel/iommu.c:178:30: error: 'fail_iommu_bus_notifier' defined but not used [-Werror=unused-variable]
178 | static struct notifier_block fail_iommu_bus_notifier = {
--- arch/powerpc/Kconfig.debug | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/Kconfig.debug +1 -0
@@ -352,6 +352,7 @@ config PPC_EARLY_DEBUG_CPM_ADDR config FAIL_IOMMU bool "Fault-injection capability for IOMMU" depends on FAULT_INJECTION + depends on PCI || IBMVIO help Provide fault-injection capability for IOMMU. Each device can be selectively enabled via the fail_iommu property.
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 189/244 mac80211: bail out if cipher schemes are invalid
In reply to Greg Kroah-HartmanFrom: Johannes Berg <[email protected]>
[ Upstream commit db878e27a98106a70315d264cc92230d84009e72 ]
If any of the cipher schemes specified by the driver are invalid, bail out and fail the registration rather than just warning. Otherwise, we might later crash when we try to use the invalid cipher scheme, e.g. if the hdr_len is (significantly) less than the pn_offs + pn_len, we'd have an out-of-bounds access in RX validation.
--- net/mac80211/main.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
net/mac80211/main.c +5 -2
@@ -1113,8 +1113,11 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)if (local->hw.wiphy->max_scan_ie_len) local->hw.wiphy->max_scan_ie_len -= local->scan_ies_len; -WARN_ON (!ieee80211_cs_list_valid (local->hw.cipher_schemes, - local->hw.n_cipher_schemes)); +if (WARN_ON (!ieee80211_cs_list_valid (local->hw.cipher_schemes, + local->hw.n_cipher_schemes))) { + result = -EINVAL ; + goto fail_workqueue; + } result =ieee80211_init_cipher_suites (local);if (result <0 )
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 190/244 mt7601u: fix always true expression
In reply to Greg Kroah-HartmanFrom: Colin Ian King <[email protected]>
[ Upstream commit 87fce88658ba047ae62e83497d3f3c5dc22fa6f9 ]
Currently the expression ~nic_conf1 is always true because nic_conf1 is a u16 and according to 6.5.3.3 of the C standard the ~ operator promotes the u16 to an integer before flipping all the bits. Thus the top 16 bits of the integer result are all set so the expression is always true. If the intention was to flip all the bits of nic_conf1 then casting the integer result back to a u16 is a suitabel fix.
Interestingly static analyzers seem to thing a bitwise ! should be used instead of ~ for this scenario, so I think the original intent of the expression may need some extra consideration.
Addresses-Coverity: ("Logical vs. bitwise operator")
--- drivers/net/wireless/mediatek/mt7601u/eeprom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/mediatek/mt7601u/eeprom.c +1 -1
@@ -99,7 +99,7 @@ mt7601u_has_tssi(struct mt7601u_dev *dev, u8 *eeprom) {u16 nic_conf1 =get_unaligned_le16 (eeprom +MT_EE_NIC_CONF_1 ); -return ~nic_conf1 && (nic_conf1 &MT_EE_NIC_CONF_1_TX_ALC_EN ); +return (u16 )~nic_conf1 && (nic_conf1 &MT_EE_NIC_CONF_1_TX_ALC_EN ); } static void
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 191/244 KVM: PPC: Book3S HV P9: Restore host CTRL SPR after guest exit
In reply to Greg Kroah-HartmanFrom: Nicholas Piggin <[email protected]>
[ Upstream commit 5088eb4092df12d701af8e0e92860b7186365279 ]
The host CTRL (runlatch) value is not restored after guest exit. The host CTRL should always be 1 except in CPU idle code, so this can result in the host running with runlatch clear, and potentially switching to a different vCPU which then runs with runlatch clear as well.
This has little effect on P9 machines, CTRL is only responsible for some PMU counter logic in the host and so other than corner cases of software relying on that, or explicitly reading the runlatch value (Linux does not appear to be affected but it's possible non-Linux guests could be), there should be no execution correctness problem, though it could be used as a covert channel between guests.
There may be microcontrollers, firmware or monitoring tools that sample the runlatch value out-of-band, however since the register is writable by guests, these values would (should) not be relied upon for correct operation of the host, so suboptimal performance or incorrect reporting should be the worst problem.
--- arch/powerpc/kvm/book3s_hv.c | 3 +++ 1 file changed, 3 insertions(+)
arch/powerpc/kvm/book3s_hv.c +3 -0
@@ -3638,7 +3638,10 @@ int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit, vcpu->arch.dec_expires = dec + tb; vcpu->cpu =-1 ; vcpu->arch.thread_cpu =-1 ; +/* Save guest CTRL register, set runlatch to 1 */ vcpu->arch.ctrl =mfspr (SPRN_CTRLF ); +if (!(vcpu->arch.ctrl &1 )) +mtspr (SPRN_CTRLT , vcpu->arch.ctrl |1 ); vcpu->arch.iamr =mfspr (SPRN_IAMR ); vcpu->arch.pspb =mfspr (SPRN_PSPB );
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 192/244 RDMA/qedr: Fix error return code in qedr_iw_connect()
In reply to Greg Kroah-HartmanFrom: Wang Wensheng <[email protected]>
[ Upstream commit 10dd83dbcd157baf7a78a09ddb2f84c627bc7f1d ]
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function.
--- drivers/infiniband/hw/qedr/qedr_iw_cm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/infiniband/hw/qedr/qedr_iw_cm.c +3 -1
@@ -636,8 +636,10 @@ int qedr_iw_connect(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)memcpy (in_params.local_mac_addr, dev->ndev->dev_addr,ETH_ALEN );if (test_and_set_bit (QEDR_IWARP_CM_WAIT_FOR_CONNECT , - &qp->iwarp_cm_flags)) + &qp->iwarp_cm_flags)) { + rc = -ENODEV ; goto err;/* QP already being destroyed */ + } rc = dev->ops->iwarp_connect (dev->rdma_ctx, &in_params, &out_params);if (rc) {
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 193/244 IB/hfi1: Fix error return code in parse_platform_config()
In reply to Greg Kroah-HartmanFrom: Wang Wensheng <[email protected]>
[ Upstream commit 4c7d9c69adadfc31892c7e8e134deb3546552106 ]
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function.
--- drivers/infiniband/hw/hfi1/firmware.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/hw/hfi1/firmware.c +1 -0
@@ -1924,6 +1924,7 @@ int parse_platform_config(struct hfi1_devdata *dd)dd_dev_err (dd,"%s: Failed CRC check at offset %ld\n" , __func__, (ptr - (u32 *)dd->platform_config.data)); + ret = -EINVAL ; goto bail; }/* Jump the CRC DWORD */
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 194/244 cxgb4: Fix unintentional sign extension issues
In reply to Greg Kroah-HartmanFrom: Colin Ian King <[email protected]>
[ Upstream commit dd2c79677375c37f8f9f8d663eb4708495d595ef ]
The shifting of the u8 integers f->fs.nat_lip[] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that the top bit of the u8 is set then all then all the upper 32 bits of the u64 end up as also being set because of the sign-extension. Fix this by casting the u8 values to a u64 before the 24 bit left shift.
Addresses-Coverity: ("Unintended sign extension")
--- .../net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +11 -11
@@ -174,31 +174,31 @@ static void set_nat_params(struct adapter *adap, struct filter_entry *f,WORD_MASK , f->fs.nat_lip[15 ] | f->fs.nat_lip[14 ] <<8 | f->fs.nat_lip[13 ] <<16 | - f->fs.nat_lip[12] << 24, 1); + (u64)f->fs.nat_lip[12] << 24, 1);set_tcb_field (adap, f, tid,TCB_SND_UNA_RAW_W +1 ,WORD_MASK , f->fs.nat_lip[11 ] | f->fs.nat_lip[10 ] <<8 | f->fs.nat_lip[9 ] <<16 | - f->fs.nat_lip[8 ] <<24 ,1 ); + (u64 )f->fs.nat_lip[8 ] <<24 ,1 );set_tcb_field (adap, f, tid,TCB_SND_UNA_RAW_W +2 ,WORD_MASK , f->fs.nat_lip[7 ] | f->fs.nat_lip[6 ] <<8 | f->fs.nat_lip[5 ] <<16 | - f->fs.nat_lip[4 ] <<24 ,1 ); + (u64 )f->fs.nat_lip[4 ] <<24 ,1 );set_tcb_field (adap, f, tid,TCB_SND_UNA_RAW_W +3 ,WORD_MASK , f->fs.nat_lip[3 ] | f->fs.nat_lip[2 ] <<8 | f->fs.nat_lip[1 ] <<16 | - f->fs.nat_lip[0 ] <<24 ,1 ); + (u64 )f->fs.nat_lip[0 ] <<24 ,1 ); }else {set_tcb_field (adap, f, tid,TCB_RX_FRAG3_LEN_RAW_W ,WORD_MASK , f->fs.nat_lip[3 ] | f->fs.nat_lip[2 ] <<8 | f->fs.nat_lip[1 ] <<16 | - f->fs.nat_lip[0 ] <<24 ,1 ); + (u64 )f->fs.nat_lip[0 ] <<25 ,1 ); } }
@@ -208,25 +208,25 @@ static void set_nat_params(struct adapter *adap, struct filter_entry *f,WORD_MASK , f->fs.nat_fip[15 ] | f->fs.nat_fip[14 ] <<8 | f->fs.nat_fip[13 ] <<16 | - f->fs.nat_fip[12] << 24, 1); + (u64)f->fs.nat_fip[12] << 24, 1);set_tcb_field (adap, f, tid,TCB_RX_FRAG2_PTR_RAW_W +1 ,WORD_MASK , f->fs.nat_fip[11 ] | f->fs.nat_fip[10 ] <<8 | f->fs.nat_fip[9 ] <<16 | - f->fs.nat_fip[8 ] <<24 ,1 ); + (u64 )f->fs.nat_fip[8 ] <<24 ,1 );set_tcb_field (adap, f, tid,TCB_RX_FRAG2_PTR_RAW_W +2 ,WORD_MASK , f->fs.nat_fip[7 ] | f->fs.nat_fip[6 ] <<8 | f->fs.nat_fip[5 ] <<16 | - f->fs.nat_fip[4 ] <<24 ,1 ); + (u64 )f->fs.nat_fip[4 ] <<24 ,1 );set_tcb_field (adap, f, tid,TCB_RX_FRAG2_PTR_RAW_W +3 ,WORD_MASK , f->fs.nat_fip[3 ] | f->fs.nat_fip[2 ] <<8 | f->fs.nat_fip[1 ] <<16 | - f->fs.nat_fip[0 ] <<24 ,1 ); + (u64 )f->fs.nat_fip[0 ] <<24 ,1 ); }else { set_tcb_field(adap, f, tid,
@@ -234,13 +234,13 @@ static void set_nat_params(struct adapter *adap, struct filter_entry *f,WORD_MASK , f->fs.nat_fip[3 ] | f->fs.nat_fip[2 ] <<8 | f->fs.nat_fip[1 ] <<16 | - f->fs.nat_fip[0] << 24, 1); + (u64)f->fs.nat_fip[0] << 24, 1); } }set_tcb_field (adap, f, tid,TCB_PDU_HDR_LEN_W ,WORD_MASK , (dp ? (nat_lp[1 ] | nat_lp[0 ] <<8 ) :0 ) | - (sp ? (nat_fp[1 ] <<16 | nat_fp[0 ] <<24 ) :0 ), + (sp ? (nat_fp[1 ] <<16 | (u64 )nat_fp[0 ] <<24 ) :0 ),1 ); }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 195/244 net: thunderx: Fix unintentional sign extension issue
In reply to Greg Kroah-HartmanFrom: Colin Ian King <[email protected]>
[ Upstream commit e701a25840360706fe4cf5de0015913ca19c274b ]
The shifting of the u8 integers rq->caching by 26 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that rq->caching is greater than 0x1f then all then all the upper 32 bits of the u64 end up as also being set because of the int sign-extension. Fix this by casting the u8 values to a u64 before the 26 bit left shift.
Addresses-Coverity: ("Unintended sign extension")
--- drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/cavium/thunder/nicvf_queues.c +1 -1
@@ -776,7 +776,7 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs, mbx.rq.msg =NIC_MBOX_MSG_RQ_CFG ; mbx.rq.qs_num = qs->vnic_id; mbx.rq.rq_num = qidx; - mbx.rq.cfg = (rq->caching <<26 ) | (rq->cq_qs <<19 ) | + mbx.rq.cfg = ((u64 )rq->caching <<26 ) | (rq->cq_qs <<19 ) | (rq->cq_idx <<16 ) | (rq->cont_rbdr_qs <<9 ) | (rq->cont_qs_rbdr_idx <<8 ) | (rq->start_rbdr_qs <<1 ) | (rq->start_qs_rbdr_idx);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 196/244 RDMA/srpt: Fix error return code in srpt_cm_req_recv()
In reply to Greg Kroah-HartmanFrom: Wang Wensheng <[email protected]>
[ Upstream commit 6bc950beff0c440ac567cdc4e7f4542a9920953d ]
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function.
--- drivers/infiniband/ulp/srpt/ib_srpt.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/ulp/srpt/ib_srpt.c +1 -0
@@ -2373,6 +2373,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,pr_info ("rejected SRP_LOGIN_REQ because target %s_%d is not enabled\n" ,dev_name (&sdev->device->dev), port_num);mutex_unlock (&sport->mutex); + ret = -EINVAL ; goto reject; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 197/244 i2c: img-scb: fix reference leak when pm_runtime_get_sync fails
In reply to Greg Kroah-HartmanFrom: Qinglang Miao <[email protected]>
[ Upstream commit 223125e37af8a641ea4a09747a6a52172fc4b903 ]
The PM reference count is not expected to be incremented on return in functions img_i2c_xfer and img_i2c_init.
However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage counter balanced.
--- drivers/i2c/busses/i2c-img-scb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-img-scb.c +2 -2
@@ -1057,7 +1057,7 @@ static int img_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, atomic = true; } - ret =pm_runtime_get_sync (adap->dev.parent); + ret =pm_runtime_resume_and_get (adap->dev.parent);if (ret <0 )return ret;
@@ -1158,7 +1158,7 @@ static int img_i2c_init(struct img_i2c *i2c)u32 rev;int ret; - ret =pm_runtime_get_sync (i2c->adap.dev.parent); + ret =pm_runtime_resume_and_get (i2c->adap.dev.parent);if (ret <0 )return ret;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 198/244 i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails
In reply to Greg Kroah-HartmanFrom: Qinglang Miao <[email protected]>
[ Upstream commit 278e5bbdb9a94fa063c0f9bcde2479d0b8042462 ]
The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable.
However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage counter balanced.
--- drivers/i2c/busses/i2c-imx-lpi2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i2c/busses/i2c-imx-lpi2c.c +1 -1
@@ -265,7 +265,7 @@ static int lpi2c_imx_master_enable(struct lpi2c_imx_struct *lpi2c_imx)unsigned int temp;int ret; - ret =pm_runtime_get_sync (lpi2c_imx->adapter.dev.parent); + ret =pm_runtime_resume_and_get (lpi2c_imx->adapter.dev.parent);if (ret <0 )return ret;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 199/244 i2c: omap: fix reference leak when pm_runtime_get_sync fails
In reply to Greg Kroah-HartmanFrom: Qinglang Miao <[email protected]>
[ Upstream commit 780f629741257ed6c54bd3eb53b57f648eabf200 ]
The PM reference count is not expected to be incremented on return in omap_i2c_probe() and omap_i2c_remove().
However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. I Replace it with pm_runtime_resume_and_get to keep usage counter balanced.
What's more, error path 'err_free_mem' seems not like a proper name any more. So I change the name to err_disable_pm and move pm_runtime_disable below, for pm_runtime of 'pdev->dev' should be disabled when pm_runtime_resume_and_get fails.
--- drivers/i2c/busses/i2c-omap.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/i2c/busses/i2c-omap.c +4 -4
@@ -1408,9 +1408,9 @@ omap_i2c_probe(struct platform_device *pdev)pm_runtime_set_autosuspend_delay (omap->dev,OMAP_I2C_PM_TIMEOUT );pm_runtime_use_autosuspend (omap->dev); - r =pm_runtime_get_sync (omap->dev); + r =pm_runtime_resume_and_get (omap->dev);if (r <0 ) - goto err_free_mem; + goto err_disable_pm;/* * Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
@@ -1518,8 +1518,8 @@ err_unuse_clocks:omap_i2c_write_reg (omap,OMAP_I2C_CON_REG ,0 );pm_runtime_dont_use_autosuspend (omap->dev);pm_runtime_put_sync (omap->dev); +err_disable_pm:pm_runtime_disable (&pdev->dev); -err_free_mem:return r; }
@@ -1530,7 +1530,7 @@ static int omap_i2c_remove(struct platform_device *pdev)int ret;i2c_del_adapter (&omap->adapter); - ret =pm_runtime_get_sync (&pdev->dev); + ret =pm_runtime_resume_and_get (&pdev->dev);if (ret <0 )return ret;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 200/244 i2c: sprd: fix reference leak when pm_runtime_get_sync fails
In reply to Greg Kroah-HartmanFrom: Qinglang Miao <[email protected]>
[ Upstream commit 3a4f326463117cee3adcb72999ca34a9aaafda93 ]
The PM reference count is not expected to be incremented on return in sprd_i2c_master_xfer() and sprd_i2c_remove().
However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage counter balanced.
--- drivers/i2c/busses/i2c-sprd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-sprd.c +2 -2
@@ -290,7 +290,7 @@ static int sprd_i2c_master_xfer(struct i2c_adapter *i2c_adap,struct sprd_i2c *i2c_dev = i2c_adap->algo_data;int im, ret; - ret =pm_runtime_get_sync (i2c_dev->dev); + ret =pm_runtime_resume_and_get (i2c_dev->dev);if (ret <0 )return ret;
@@ -577,7 +577,7 @@ static int sprd_i2c_remove(struct platform_device *pdev)struct sprd_i2c *i2c_dev =platform_get_drvdata (pdev);int ret; - ret =pm_runtime_get_sync (i2c_dev->dev); + ret =pm_runtime_resume_and_get (i2c_dev->dev);if (ret <0 )return ret;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 201/244 i2c: cadence: add IRQ check
In reply to Greg Kroah-HartmanFrom: Sergey Shtylyov <[email protected]>
[ Upstream commit 5581c2c5d02bc63a0edb53e061c8e97cd490646e ]
The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s.
--- drivers/i2c/busses/i2c-cadence.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/i2c/busses/i2c-cadence.c +4 -1
@@ -901,7 +901,10 @@ static int cdns_i2c_probe(struct platform_device *pdev)if (IS_ERR (id->membase))return PTR_ERR (id->membase); - id->irq =platform_get_irq (pdev,0 ); + ret =platform_get_irq (pdev,0 ); +if (ret <0 ) +return ret; + id->irq = ret; id->adap.owner =THIS_MODULE ; id->adap.dev.of_node = pdev->dev.of_node;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 202/244 i2c: emev2: add IRQ check
In reply to Greg Kroah-HartmanFrom: Sergey Shtylyov <[email protected]>
[ Upstream commit bb6129c32867baa7988f7fd2066cf18ed662d240 ]
The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s.
--- drivers/i2c/busses/i2c-emev2.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/i2c/busses/i2c-emev2.c +4 -1
@@ -397,7 +397,10 @@ static int em_i2c_probe(struct platform_device *pdev)em_i2c_reset (&priv->adap); - priv->irq =platform_get_irq (pdev,0 ); + ret =platform_get_irq (pdev,0 ); +if (ret <0 ) + goto err_clk; + priv->irq = ret; ret =devm_request_irq (&pdev->dev, priv->irq, em_i2c_irq_handler,0 ,"em_i2c" , priv);if (ret)
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 203/244 i2c: jz4780: add IRQ check
In reply to Greg Kroah-HartmanFrom: Sergey Shtylyov <[email protected]>
[ Upstream commit c5e5f7a8d931fb4beba245bdbc94734175fda9de ]
The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s.
--- drivers/i2c/busses/i2c-jz4780.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/i2c/busses/i2c-jz4780.c +4 -1
@@ -751,7 +751,10 @@ static int jz4780_i2c_probe(struct platform_device *pdev)jz4780_i2c_writew (i2c,JZ4780_I2C_INTM ,0x0 ); - i2c->irq =platform_get_irq (pdev,0 ); + ret =platform_get_irq (pdev,0 ); +if (ret <0 ) + goto err; + i2c->irq = ret; ret =devm_request_irq (&pdev->dev, i2c->irq, jz4780_i2c_irq,0 ,dev_name (&pdev->dev), i2c);if (ret)
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 204/244 i2c: sh7760: add IRQ check
In reply to Greg Kroah-HartmanFrom: Sergey Shtylyov <[email protected]>
[ Upstream commit e5b2e3e742015dd2aa6bc7bcef2cb59b2de1221c ]
The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s.
--- drivers/i2c/busses/i2c-sh7760.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/i2c/busses/i2c-sh7760.c +4 -1
@@ -471,7 +471,10 @@ static int sh7760_i2c_probe(struct platform_device *pdev) goto out2; } - id->irq =platform_get_irq (pdev,0 ); + ret =platform_get_irq (pdev,0 ); +if (ret <0 ) +return ret; + id->irq = ret; id->adap.nr = pdev->id; id->adap.algo = &sh7760_i2c_algo;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 205/244 powerpc/xive: Fix xmon command "dxi"
In reply to Greg Kroah-HartmanFrom: Cédric Le Goater <[email protected]>
[ Upstream commit 33e4bc5946432a4ac173fd08e8e30a13ab94d06d ]
When under xmon, the "dxi" command dumps the state of the XIVE interrupts. If an interrupt number is specified, only the state of the associated XIVE interrupt is dumped. This form of the command lacks an irq_data parameter which is nevertheless used by xmon_xive_get_irq_config(), leading to an xmon crash.
Fix that by doing a lookup in the system IRQ mapping to query the IRQ descriptor data. Invalid interrupt numbers, or not belonging to the XIVE IRQ domain, OPAL event interrupt number for instance, should be caught by the previous query done at the firmware level.
--- arch/powerpc/sysdev/xive/common.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
arch/powerpc/sysdev/xive/common.c +10 -4
@@ -257,17 +257,20 @@ notrace void xmon_xive_do_dump(int cpu)xmon_printf ("\n" ); } +static struct irq_data *xive_get_irq_data (u32 hw_irq) +{ +unsigned int irq =irq_find_mapping (xive_irq_domain, hw_irq); + +return irq ?irq_get_irq_data (irq) :NULL ; +} +int xmon_xive_get_irq_config (u32 hw_irq,struct irq_data *d) { -struct irq_chip *chip =irq_data_get_irq_chip (d);int rc;u32 target;u8 prio;u32 lirq; -if (!is_xive_irq (chip)) -return -EINVAL ; - rc = xive_ops->get_irq_config (hw_irq, &target, &prio, &lirq);if (rc) {xmon_printf ("IRQ 0x%08x : no config rc=%d\n" , hw_irq, rc);
@@ -277,6 +280,9 @@ int xmon_xive_get_irq_config(u32 hw_irq, struct irq_data *d)xmon_printf ("IRQ 0x%08x : target=0x%x prio=%02x lirq=0x%x " , hw_irq, target, prio, lirq); +if (!d) + d =xive_get_irq_data (hw_irq); +if (d) {struct xive_irq_data *xd =irq_data_get_irq_handler_data (d);u64 val =xive_esb_read (xd,XIVE_ESB_GET );
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 206/244 ASoC: ak5558: correct reset polarity
In reply to Greg Kroah-HartmanFrom: Shengjiu Wang <[email protected]>
[ Upstream commit 0b93bbc977af55fd10687f2c96c807cba95cb927 ]
Reset (aka power off) happens when the reset gpio is made active. The reset gpio is GPIO_ACTIVE_LOW
--- sound/soc/codecs/ak5558.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/soc/codecs/ak5558.c +2 -2
@@ -264,7 +264,7 @@ static void ak5558_power_off(struct ak5558_priv *ak5558)if (!ak5558->reset_gpiod)return ; -gpiod_set_value_cansleep (ak5558->reset_gpiod,0 ); +gpiod_set_value_cansleep (ak5558->reset_gpiod,1 );usleep_range (1000 ,2000 ); }
@@ -273,7 +273,7 @@ static void ak5558_power_on(struct ak5558_priv *ak5558)if (!ak5558->reset_gpiod)return ; -gpiod_set_value_cansleep (ak5558->reset_gpiod,1 ); +gpiod_set_value_cansleep (ak5558->reset_gpiod,0 );usleep_range (1000 ,2000 ); }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 207/244 drm/i915/gvt: Fix error code in intel_gvt_init_device()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit 329328ec6a87f2c1275f50d979d55513de458409 ]
The intel_gvt_init_vgpu_type_groups() function is only called from intel_gvt_init_device(). If it fails then the intel_gvt_init_device() prints the error code and propagates it back again. That's a bug because false is zero/success. The fix is to modify it to return zero or negative error codes and make everything consistent.
--- drivers/gpu/drm/i915/gvt/gvt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/i915/gvt/gvt.c +4 -4
@@ -128,7 +128,7 @@ static bool intel_get_gvt_attrs(struct attribute ***type_attrs,return true; } -static bool intel_gvt_init_vgpu_type_groups (struct intel_gvt *gvt) +static int intel_gvt_init_vgpu_type_groups (struct intel_gvt *gvt) {int i, j;struct intel_vgpu_type *type;
@@ -146,7 +146,7 @@ static bool intel_gvt_init_vgpu_type_groups(struct intel_gvt *gvt) gvt_vgpu_type_groups[i] = group; } -return true; +return 0 ; unwind:for (j =0 ; j < i; j++) {
@@ -154,7 +154,7 @@ unwind:kfree (group); } -return false; +return -ENOMEM ; }static void intel_gvt_cleanup_vgpu_type_groups (struct intel_gvt *gvt)
@@ -362,7 +362,7 @@ int intel_gvt_init_device(struct drm_i915_private *dev_priv) goto out_clean_thread; ret =intel_gvt_init_vgpu_type_groups (gvt); -if (ret == false) { +if (ret) {gvt_err ("failed to init vgpu type groups: %d\n" , ret); goto out_clean_types; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 208/244 perf beauty: Fix fsconfig generator
In reply to Greg Kroah-HartmanFrom: Vitaly Chikunov <[email protected]>
[ Upstream commit 2e1daee14e67fbf9b27280b974e2c680a22cabea ]
After gnulib update sed stopped matching `[[:space:]]*+' as before, causing the following compilation error:
In file included from builtin-trace.c:719:
trace/beauty/generated/fsconfig_arrays.c:2:3: error: expected expression before ']' token
2 | [] = "", | ^
trace/beauty/generated/fsconfig_arrays.c:2:3: error: array index in initializer not of integer type trace/beauty/generated/fsconfig_arrays.c:2:3: note: (near initialization for 'fsconfig_cmds')
Fix this by correcting the regular expression used in the generator. Also, clean up the script by removing redundant egrep, xargs, and printf invocations.
Committer testing:
Continues to work:
$ cat tools/perf/trace/beauty/fsconfig.sh #!/bin/sh # SPDX-License-Identifier: LGPL-2.1
if [ $# -ne 1 ] ; then
linux_header_dir=tools/include/uapi/linux
else
linux_header_dir=$1
fi
linux_mount=${linux_header_dir}/mount.h
printf "static const char *fsconfig_cmds[] = {\n"
ms='[[:space:]]*'
sed -nr "s/^${ms}FSCONFIG_([[:alnum:]_]+)${ms}=${ms}([[:digit:]]+)${ms},.*/\t[\2] = \"\1\",/p" \
${linux_mount}
printf "};\n"
$ tools/perf/trace/beauty/fsconfig.sh
static const char *fsconfig_cmds[] = {
[0] = "SET_FLAG",
[1] = "SET_STRING",
[2] = "SET_BINARY",
[3] = "SET_PATH",
[4] = "SET_PATH_EMPTY",
[5] = "SET_FD",
[6] = "CMD_CREATE",
[7] = "CMD_RECONFIGURE",
};
$--- tools/perf/trace/beauty/fsconfig.sh | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
tools/perf/trace/beauty/fsconfig.sh +3 -4
@@ -10,8 +10,7 @@ fi linux_mount=${linux_header_dir}/mount.h printf "static const char *fsconfig_cmds[] = {\n" -regex='^[[:space:]]*+FSCONFIG_([[:alnum:]_]+)[[:space:]]*=[[:space:]]*([[:digit:]]+)[[:space:]]*,[[:space:]]*.*' -egrep $regex ${linux_mount} | \ - sed -r "s/$regex/\2 \1/g" | \ - xargs printf "\t[%s] = \"%s\",\n" +ms='[[:space:]]*' +sed -nr "s/^${ms}FSCONFIG_([[:alnum:]_]+)${ms}=${ms}([[:digit:]]+)${ms},.*/\t[\2] = \"\1\",/p" \ + ${linux_mount} printf "};\n"
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 209/244 MIPS: pci-legacy: stop using of_pci_range_to_resource
In reply to Greg Kroah-HartmanFrom: Ilya Lipnitskiy <[email protected]>
[ Upstream commit 3ecb9dc1581eebecaee56decac70e35365260866 ]
Mirror commit aeba3731b150 ("powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change").
Most MIPS platforms do not define PCI_IOBASE, nor implement pci_address_to_pio(). Moreover, IO_SPACE_LIMIT is 0xffff for most MIPS platforms. of_pci_range_to_resource passes the _start address_ of the IO range into pci_address_to_pio, which then checks it against IO_SPACE_LIMIT and fails, because for MIPS platforms that use pci-legacy (pci-lantiq, pci-rt3883, pci-mt7620), IO ranges start much higher than 0xffff.
In fact, pci-mt7621 in staging already works around this problem, see commit 09dd629eeabb ("staging: mt7621-pci: fix io space and properly set resource limits")
So just stop using of_pci_range_to_resource, which does not work for MIPS.
Fixes PCI errors like:
pci_bus 0000:00: root bus resource [io 0xffffffff]
--- arch/mips/pci/pci-legacy.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
arch/mips/pci/pci-legacy.c +7 -2
@@ -166,8 +166,13 @@ void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node) res = hose->mem_resource;break ; } -if (res !=NULL ) -of_pci_range_to_resource (&range, node, res); +if (res !=NULL ) { + res->name = node->full_name; + res->flags = range.flags; + res->start = range.cpu_addr; + res->end = range.cpu_addr + range.size -1 ; + res->parent = res->child = res->sibling =NULL ; + } } }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 210/244 powerpc/pseries: extract host bridge from pci_bus prior to bus removal
In reply to Greg Kroah-HartmanFrom: Tyrel Datwyler <[email protected]>
[ Upstream commit 38d0b1c9cec71e6d0f3bddef0bbce41d05a3e796 ]
The pci_bus->bridge reference may no longer be valid after pci_bus_remove() resulting in passing a bad value to device_unregister() for the associated bridge device.
Store the host_bridge reference in a separate variable prior to pci_bus_remove().
--- arch/powerpc/platforms/pseries/pci_dlpar.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/powerpc/platforms/pseries/pci_dlpar.c +3 -1
@@ -66,6 +66,7 @@ EXPORT_SYMBOL_GPL(init_phb_dynamic);int remove_phb_dynamic (struct pci_controller *phb) {struct pci_bus *b = phb->bus; +struct pci_host_bridge *host_bridge =to_pci_host_bridge (b->bridge);struct resource *res;int rc, i;
@@ -92,7 +93,8 @@ int remove_phb_dynamic(struct pci_controller *phb)/* Remove the PCI bus and unregister the bridge device from sysfs */ phb->bus =NULL ;pci_remove_bus (b); -device_unregister (b->bridge); + host_bridge->bus =NULL ; +device_unregister (&host_bridge->dev);/* Now release the IO resource */ if (res->flags &IORESOURCE_IO )
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 211/244 rtlwifi: 8821ae: upgrade PHY and RF parameters
In reply to Greg Kroah-HartmanFrom: Ping-Ke Shih <[email protected]>
[ Upstream commit 18fb0bedb5fc2fddc057dbe48b7360a6ffda34b3 ]
The signal strength of 5G is quite low, so user can't connect to an AP far away. New parameters with new format and its parser are updated by the commit 84d26fda52e2 ("rtlwifi: Update 8821ae new phy parameters and its parser."), but some parameters are missing. Use this commit to update to the novel parameters that use new format.
--- .../realtek/rtlwifi/rtl8821ae/table.c | 500 +++++++++++++----- 1 file changed, 370 insertions(+), 130 deletions(-)
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.c +370 -130
@@ -249,7 +249,7 @@ u32 RTL8821AE_PHY_REG_ARRAY[] = {0x824 ,0x00030FE0 ,0x828 ,0x00000000 ,0x82C ,0x002081DD , -0x830 ,0x2AAA8E24 , +0x830 ,0x2AAAEEC8 ,0x834 ,0x0037A706 ,0x838 ,0x06489B44 , 0x83C, 0x0000095B,
@@ -324,10 +324,10 @@ u32 RTL8821AE_PHY_REG_ARRAY[] = {0x9D8 ,0x00000000 ,0x9DC ,0x00000000 ,0x9E0 ,0x00005D00 , -0x9E4 ,0x00000002 , +0x9E4 ,0x00000003 ,0x9E8 ,0x00000001 ,0xA00 ,0x00D047C8 , -0xA04 ,0x01FF000C , +0xA04 ,0x01FF800C ,0xA08 ,0x8C8A8300 ,0xA0C ,0x2E68000F , 0xA10, 0x9500BB78,
@@ -1320,7 +1320,11 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x083 ,0x00021800 ,0x084 ,0x00028000 ,0x085 ,0x00048000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 , +0x086 ,0x0009483A , +0xA0000000 ,0x00000000 ,0x086 ,0x00094838 , +0xB0000000 ,0x00000000 ,0x087 ,0x00044980 ,0x088 ,0x00048000 , 0x089, 0x0000D480,
@@ -1409,36 +1413,32 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x03C ,0x000CA000 ,0x0EF ,0x00000000 ,0x0EF ,0x00001100 , -0xFF0F0104 ,0xABCD , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x0004ADF3 ,0x034 ,0x00049DF0 , -0xFF0F0204 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x0004ADF3 ,0x034 ,0x00049DF0 , -0xFF0F0404 ,0xCDEF , -0x034 ,0x0004ADF3 , -0x034 ,0x00049DF0 , -0xFF0F0200 ,0xCDEF , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x0004ADF5 ,0x034 ,0x00049DF2 , -0xFF0F02C0 ,0xCDEF , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x0004A0F3 , +0x034 ,0x000490B1 , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x0004A0F3 ,0x034 ,0x000490B1 , -0xCDCDCDCD ,0xCDCD , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x0004ADF5 , +0x034 ,0x00049DF2 , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x0004ADF3 , +0x034 ,0x00049DF0 , +0xA0000000 ,0x00000000 ,0x034 ,0x0004ADF7 ,0x034 ,0x00049DF3 , -0xFF0F0104 ,0xDEAD , -0xFF0F0104 ,0xABCD , -0x034 ,0x00048DED , -0x034 ,0x00047DEA , -0x034 ,0x00046DE7 , -0x034 ,0x00045CE9 , -0x034 ,0x00044CE6 , -0x034 ,0x000438C6 , -0x034 ,0x00042886 , -0x034 ,0x00041486 , -0x034 ,0x00040447 , -0xFF0F0204 ,0xCDEF , +0xB0000000 ,0x00000000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x00048DED ,0x034 ,0x00047DEA , 0x034, 0x00046DE7,
@@ -1448,7 +1448,7 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00042886 ,0x034 ,0x00041486 ,0x034 ,0x00040447 , -0xFF0F0404 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x00048DED ,0x034 ,0x00047DEA , 0x034, 0x00046DE7,
@@ -1458,7 +1458,17 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00042886 ,0x034 ,0x00041486 ,0x034 ,0x00040447 , -0xFF0F02C0 ,0xCDEF , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x000480AE , +0x034 ,0x000470AB , +0x034 ,0x0004608B , +0x034 ,0x00045069 , +0x034 ,0x00044048 , +0x034 ,0x00043045 , +0x034 ,0x00042026 , +0x034 ,0x00041023 , +0x034 ,0x00040002 , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x000480AE ,0x034 ,0x000470AB , 0x034, 0x0004608B,
@@ -1468,7 +1478,17 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00042026 ,0x034 ,0x00041023 ,0x034 ,0x00040002 , -0xCDCDCDCD ,0xCDCD , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x00048DED , +0x034 ,0x00047DEA , +0x034 ,0x00046DE7 , +0x034 ,0x00045CE9 , +0x034 ,0x00044CE6 , +0x034 ,0x000438C6 , +0x034 ,0x00042886 , +0x034 ,0x00041486 , +0x034 ,0x00040447 , +0xA0000000 ,0x00000000 ,0x034 ,0x00048DEF ,0x034 ,0x00047DEC , 0x034, 0x00046DE9,
@@ -1478,38 +1498,36 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x0004248A ,0x034 ,0x0004108D ,0x034 ,0x0004008A , -0xFF0F0104 ,0xDEAD , -0xFF0F0200 ,0xABCD , +0xB0000000 ,0x00000000 , +0x80000210 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x0002ADF4 , -0xFF0F02C0 ,0xCDEF , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x0002A0F3 , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x0002A0F3 , -0xCDCDCDCD ,0xCDCD , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x0002ADF4 , +0xA0000000 ,0x00000000 ,0x034 ,0x0002ADF7 , -0xFF0F0200 ,0xDEAD , -0xFF0F0104 ,0xABCD , -0x034 ,0x00029DF4 , -0xFF0F0204 ,0xCDEF , +0xB0000000 ,0x00000000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x00029DF4 , -0xFF0F0404 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x00029DF4 , -0xFF0F0200 ,0xCDEF , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x00029DF1 , -0xFF0F02C0 ,0xCDEF , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x000290F0 , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x000290F0 , -0xCDCDCDCD ,0xCDCD , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x00029DF1 , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x00029DF4 , +0xA0000000 ,0x00000000 ,0x034 ,0x00029DF2 , -0xFF0F0104 ,0xDEAD , -0xFF0F0104 ,0xABCD , -0x034 ,0x00028DF1 , -0x034 ,0x00027DEE , -0x034 ,0x00026DEB , -0x034 ,0x00025CEC , -0x034 ,0x00024CE9 , -0x034 ,0x000238CA , -0x034 ,0x00022889 , -0x034 ,0x00021489 , -0x034 ,0x0002044A , -0xFF0F0204 ,0xCDEF , +0xB0000000 ,0x00000000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x00028DF1 ,0x034 ,0x00027DEE , 0x034, 0x00026DEB,
@@ -1519,7 +1537,7 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00022889 ,0x034 ,0x00021489 ,0x034 ,0x0002044A , -0xFF0F0404 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x00028DF1 ,0x034 ,0x00027DEE , 0x034, 0x00026DEB,
@@ -1529,7 +1547,7 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00022889 ,0x034 ,0x00021489 ,0x034 ,0x0002044A , -0xFF0F02C0 ,0xCDEF , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x000280AF ,0x034 ,0x000270AC , 0x034, 0x0002608B,
@@ -1539,7 +1557,27 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00022026 ,0x034 ,0x00021023 ,0x034 ,0x00020002 , -0xCDCDCDCD ,0xCDCD , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x000280AF , +0x034 ,0x000270AC , +0x034 ,0x0002608B , +0x034 ,0x00025069 , +0x034 ,0x00024048 , +0x034 ,0x00023045 , +0x034 ,0x00022026 , +0x034 ,0x00021023 , +0x034 ,0x00020002 , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x00028DF1 , +0x034 ,0x00027DEE , +0x034 ,0x00026DEB , +0x034 ,0x00025CEC , +0x034 ,0x00024CE9 , +0x034 ,0x000238CA , +0x034 ,0x00022889 , +0x034 ,0x00021489 , +0x034 ,0x0002044A , +0xA0000000 ,0x00000000 ,0x034 ,0x00028DEE ,0x034 ,0x00027DEB , 0x034, 0x00026CCD,
@@ -1549,27 +1587,24 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00022849 ,0x034 ,0x00021449 ,0x034 ,0x0002004D , -0xFF0F0104 ,0xDEAD , -0xFF0F02C0 ,0xABCD , +0xB0000000 ,0x00000000 , +0x8000020c ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x0000A0D7 , +0x034 ,0x000090D3 , +0x034 ,0x000080B1 , +0x034 ,0x000070AE , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x0000A0D7 ,0x034 ,0x000090D3 ,0x034 ,0x000080B1 ,0x034 ,0x000070AE , -0xCDCDCDCD ,0xCDCD , +0xA0000000 ,0x00000000 ,0x034 ,0x0000ADF7 ,0x034 ,0x00009DF4 ,0x034 ,0x00008DF1 ,0x034 ,0x00007DEE , -0xFF0F02C0 ,0xDEAD , -0xFF0F0104 ,0xABCD , -0x034 ,0x00006DEB , -0x034 ,0x00005CEC , -0x034 ,0x00004CE9 , -0x034 ,0x000038CA , -0x034 ,0x00002889 , -0x034 ,0x00001489 , -0x034 ,0x0000044A , -0xFF0F0204 ,0xCDEF , +0xB0000000 ,0x00000000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x00006DEB ,0x034 ,0x00005CEC , 0x034, 0x00004CE9,
@@ -1577,7 +1612,7 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00002889 ,0x034 ,0x00001489 ,0x034 ,0x0000044A , -0xFF0F0404 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x00006DEB ,0x034 ,0x00005CEC , 0x034, 0x00004CE9,
@@ -1585,7 +1620,7 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00002889 ,0x034 ,0x00001489 ,0x034 ,0x0000044A , -0xFF0F02C0 ,0xCDEF , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 ,0x034 ,0x0000608D ,0x034 ,0x0000506B , 0x034, 0x0000404A,
@@ -1593,7 +1628,23 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00002044 ,0x034 ,0x00001025 ,0x034 ,0x00000004 , -0xCDCDCDCD ,0xCDCD , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x0000608D , +0x034 ,0x0000506B , +0x034 ,0x0000404A , +0x034 ,0x00003047 , +0x034 ,0x00002044 , +0x034 ,0x00001025 , +0x034 ,0x00000004 , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 , +0x034 ,0x00006DEB , +0x034 ,0x00005CEC , +0x034 ,0x00004CE9 , +0x034 ,0x000038CA , +0x034 ,0x00002889 , +0x034 ,0x00001489 , +0x034 ,0x0000044A , +0xA0000000 ,0x00000000 ,0x034 ,0x00006DCD ,0x034 ,0x00005CCD , 0x034, 0x00004CCA,
@@ -1601,11 +1652,11 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x034 ,0x00002888 ,0x034 ,0x00001488 ,0x034 ,0x00000486 , -0xFF0F0104 ,0xDEAD , +0xB0000000 ,0x00000000 ,0x0EF ,0x00000000 ,0x018 ,0x0001712A ,0x0EF ,0x00000040 , -0xFF0F0104 ,0xABCD , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x035 ,0x00000187 ,0x035 ,0x00008187 , 0x035, 0x00010187,
@@ -1615,7 +1666,7 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x035 ,0x00040188 ,0x035 ,0x00048188 ,0x035 ,0x00050188 , -0xFF0F0204 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x035 ,0x00000187 ,0x035 ,0x00008187 , 0x035, 0x00010187,
@@ -1625,7 +1676,37 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x035 ,0x00040188 ,0x035 ,0x00048188 ,0x035 ,0x00050188 , -0xFF0F0404 ,0xCDEF , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 , +0x035 ,0x00000128 , +0x035 ,0x00008128 , +0x035 ,0x00010128 , +0x035 ,0x000201C8 , +0x035 ,0x000281C8 , +0x035 ,0x000301C8 , +0x035 ,0x000401C8 , +0x035 ,0x000481C8 , +0x035 ,0x000501C8 , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x035 ,0x00000145 , +0x035 ,0x00008145 , +0x035 ,0x00010145 , +0x035 ,0x00020196 , +0x035 ,0x00028196 , +0x035 ,0x00030196 , +0x035 ,0x000401C7 , +0x035 ,0x000481C7 , +0x035 ,0x000501C7 , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x035 ,0x00000128 , +0x035 ,0x00008128 , +0x035 ,0x00010128 , +0x035 ,0x000201C8 , +0x035 ,0x000281C8 , +0x035 ,0x000301C8 , +0x035 ,0x000401C8 , +0x035 ,0x000481C8 , +0x035 ,0x000501C8 , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 ,0x035 ,0x00000187 ,0x035 ,0x00008187 , 0x035, 0x00010187,
@@ -1635,7 +1716,7 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x035 ,0x00040188 ,0x035 ,0x00048188 ,0x035 ,0x00050188 , -0xCDCDCDCD ,0xCDCD , +0xA0000000 ,0x00000000 ,0x035 ,0x00000145 ,0x035 ,0x00008145 , 0x035, 0x00010145,
@@ -1645,11 +1726,11 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x035 ,0x000401C7 ,0x035 ,0x000481C7 ,0x035 ,0x000501C7 , -0xFF0F0104 ,0xDEAD , +0xB0000000 ,0x00000000 ,0x0EF ,0x00000000 ,0x018 ,0x0001712A ,0x0EF ,0x00000010 , -0xFF0F0104 ,0xABCD , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x036 ,0x00085733 ,0x036 ,0x0008D733 , 0x036, 0x00095733,
@@ -1662,7 +1743,7 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x036 ,0x000CE4B4 ,0x036 ,0x000D64B4 ,0x036 ,0x000DE4B4 , -0xFF0F0204 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x036 ,0x00085733 ,0x036 ,0x0008D733 , 0x036, 0x00095733,
@@ -1675,7 +1756,46 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x036 ,0x000CE4B4 ,0x036 ,0x000D64B4 ,0x036 ,0x000DE4B4 , -0xFF0F0404 ,0xCDEF , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 , +0x036 ,0x000063B5 , +0x036 ,0x0000E3B5 , +0x036 ,0x000163B5 , +0x036 ,0x0001E3B5 , +0x036 ,0x000263B5 , +0x036 ,0x0002E3B5 , +0x036 ,0x000363B5 , +0x036 ,0x0003E3B5 , +0x036 ,0x000463B5 , +0x036 ,0x0004E3B5 , +0x036 ,0x000563B5 , +0x036 ,0x0005E3B5 , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x036 ,0x000056B3 , +0x036 ,0x0000D6B3 , +0x036 ,0x000156B3 , +0x036 ,0x0001D6B3 , +0x036 ,0x00026634 , +0x036 ,0x0002E634 , +0x036 ,0x00036634 , +0x036 ,0x0003E634 , +0x036 ,0x000467B4 , +0x036 ,0x0004E7B4 , +0x036 ,0x000567B4 , +0x036 ,0x0005E7B4 , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x036 ,0x000063B5 , +0x036 ,0x0000E3B5 , +0x036 ,0x000163B5 , +0x036 ,0x0001E3B5 , +0x036 ,0x000263B5 , +0x036 ,0x0002E3B5 , +0x036 ,0x000363B5 , +0x036 ,0x0003E3B5 , +0x036 ,0x000463B5 , +0x036 ,0x0004E3B5 , +0x036 ,0x000563B5 , +0x036 ,0x0005E3B5 , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 ,0x036 ,0x00085733 ,0x036 ,0x0008D733 , 0x036, 0x00095733,
@@ -1688,7 +1808,7 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x036 ,0x000CE4B4 ,0x036 ,0x000D64B4 ,0x036 ,0x000DE4B4 , -0xCDCDCDCD ,0xCDCD , +0xA0000000 ,0x00000000 ,0x036 ,0x000056B3 ,0x036 ,0x0000D6B3 , 0x036, 0x000156B3,
@@ -1701,103 +1821,162 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x036 ,0x0004E7B4 ,0x036 ,0x000567B4 ,0x036 ,0x0005E7B4 , -0xFF0F0104 ,0xDEAD , +0xB0000000 ,0x00000000 ,0x0EF ,0x00000000 ,0x0EF ,0x00000008 , -0xFF0F0104 ,0xABCD , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x03C ,0x000001C8 ,0x03C ,0x00000492 , -0xFF0F0204 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x03C ,0x000001C8 ,0x03C ,0x00000492 , -0xFF0F0404 ,0xCDEF , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 , +0x03C ,0x000001B6 , +0x03C ,0x00000492 , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x03C ,0x0000022A , +0x03C ,0x00000594 , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x03C ,0x000001B6 , +0x03C ,0x00000492 , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 ,0x03C ,0x000001C8 ,0x03C ,0x00000492 , -0xCDCDCDCD ,0xCDCD , +0xA0000000 ,0x00000000 ,0x03C ,0x0000022A ,0x03C ,0x00000594 , -0xFF0F0104 ,0xDEAD , -0xFF0F0104 ,0xABCD , +0xB0000000 ,0x00000000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x03C ,0x00000800 , -0xFF0F0204 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x03C ,0x00000800 , -0xFF0F0404 ,0xCDEF , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 ,0x03C ,0x00000800 , -0xFF0F02C0 ,0xCDEF , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 ,0x03C ,0x00000820 , -0xCDCDCDCD ,0xCDCD , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x03C ,0x00000820 , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x03C ,0x00000800 , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 , +0x03C ,0x00000800 , +0xA0000000 ,0x00000000 ,0x03C ,0x00000900 , -0xFF0F0104 ,0xDEAD , +0xB0000000 ,0x00000000 ,0x0EF ,0x00000000 ,0x018 ,0x0001712A ,0x0EF ,0x00000002 , -0xFF0F0104 ,0xABCD , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x008 ,0x0004E400 , -0xFF0F0204 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x008 ,0x0004E400 , -0xFF0F0404 ,0xCDEF , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 , +0x008 ,0x00002000 , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 , +0x008 ,0x00002000 , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x008 ,0x00002000 , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x008 ,0x00002000 , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 ,0x008 ,0x0004E400 , -0xCDCDCDCD ,0xCDCD , +0xA0000000 ,0x00000000 ,0x008 ,0x00002000 , -0xFF0F0104 ,0xDEAD , +0xB0000000 ,0x00000000 ,0x0EF ,0x00000000 ,0x0DF ,0x000000C0 , -0x01F ,0x00040064 , -0xFF0F0104 ,0xABCD , +0x01F ,0x00000064 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x058 ,0x000A7284 ,0x059 ,0x000600EC , -0xFF0F0204 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x058 ,0x000A7284 ,0x059 ,0x000600EC , -0xFF0F0404 ,0xCDEF , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 , +0x058 ,0x00081184 , +0x059 ,0x0006016C , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x058 ,0x00081184 , +0x059 ,0x0006016C , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x058 ,0x00081184 , +0x059 ,0x0006016C , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 ,0x058 ,0x000A7284 ,0x059 ,0x000600EC , -0xCDCDCDCD ,0xCDCD , +0xA0000000 ,0x00000000 ,0x058 ,0x00081184 ,0x059 ,0x0006016C , -0xFF0F0104 ,0xDEAD , -0xFF0F0104 ,0xABCD , +0xB0000000 ,0x00000000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x061 ,0x000E8D73 ,0x062 ,0x00093FC5 , -0xFF0F0204 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x061 ,0x000E8D73 ,0x062 ,0x00093FC5 , -0xFF0F0404 ,0xCDEF , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 , +0x061 ,0x000EFD83 , +0x062 ,0x00093FCC , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x061 ,0x000EAD53 , +0x062 ,0x00093BC4 , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x061 ,0x000EFD83 , +0x062 ,0x00093FCC , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 ,0x061 ,0x000E8D73 ,0x062 ,0x00093FC5 , -0xCDCDCDCD ,0xCDCD , +0xA0000000 ,0x00000000 ,0x061 ,0x000EAD53 ,0x062 ,0x00093BC4 , -0xFF0F0104 ,0xDEAD , -0xFF0F0104 ,0xABCD , +0xB0000000 ,0x00000000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 ,0x063 ,0x000110E9 , -0xFF0F0204 ,0xCDEF , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 ,0x063 ,0x000110E9 , -0xFF0F0404 ,0xCDEF , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 , +0x063 ,0x000110EB , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 ,0x063 ,0x000110E9 , -0xFF0F0200 ,0xCDEF , -0x063 ,0x000710E9 , -0xFF0F02C0 ,0xCDEF , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 ,0x063 ,0x000110E9 , -0xCDCDCDCD ,0xCDCD , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x063 ,0x000110EB , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 , +0x063 ,0x000110E9 , +0xA0000000 ,0x00000000 ,0x063 ,0x000714E9 , -0xFF0F0104 ,0xDEAD , -0xFF0F0104 ,0xABCD , +0xB0000000 ,0x00000000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 , +0x064 ,0x0001C27C , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 , +0x064 ,0x0001C27C , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 ,0x064 ,0x0001C27C , -0xFF0F0204 ,0xCDEF , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x064 ,0x0001C67C , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 ,0x064 ,0x0001C27C , -0xFF0F0404 ,0xCDEF , +0x90000410 ,0x00000000 ,0x40000000 ,0x00000000 ,0x064 ,0x0001C27C , -0xCDCDCDCD ,0xCDCD , +0xA0000000 ,0x00000000 ,0x064 ,0x0001C67C , -0xFF0F0104 ,0xDEAD , -0xFF0F0200 ,0xABCD , +0xB0000000 ,0x00000000 , +0x80000111 ,0x00000000 ,0x40000000 ,0x00000000 , +0x065 ,0x00091016 , +0x90000110 ,0x00000000 ,0x40000000 ,0x00000000 , +0x065 ,0x00091016 , +0x90000210 ,0x00000000 ,0x40000000 ,0x00000000 ,0x065 ,0x00093016 , -0xFF0F02C0 ,0xCDEF , +0x9000020c ,0x00000000 ,0x40000000 ,0x00000000 ,0x065 ,0x00093015 , -0xCDCDCDCD ,0xCDCD , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 , +0x065 ,0x00093015 , +0x90000200 ,0x00000000 ,0x40000000 ,0x00000000 , +0x065 ,0x00093016 , +0xA0000000 ,0x00000000 ,0x065 ,0x00091016 , -0xFF0F0200 ,0xDEAD , +0xB0000000 ,0x00000000 ,0x018 ,0x00000006 ,0x0EF ,0x00002000 , 0x03B, 0x0003824B,
@@ -1895,9 +2074,10 @@ u32 RTL8821AE_RADIOA_ARRAY[] = {0x0B4 ,0x0001214C ,0x0B7 ,0x0003000C ,0x01C ,0x000539D2 , +0x0C4 ,0x000AFE00 ,0x018 ,0x0001F12A , -0x0FE ,0x00000000 , -0x0FE ,0x00000000 , +0xFFE ,0x00000000 , +0xFFE ,0x00000000 , 0x018, 0x0001712A, };
@@ -2017,6 +2197,7 @@ u32 RTL8812AE_MAC_REG_ARRAY[] = {u32 RTL8812AE_MAC_1T_ARRAYLEN =ARRAY_SIZE (RTL8812AE_MAC_REG_ARRAY );u32 RTL8821AE_MAC_REG_ARRAY [] = { +0x421 ,0x0000000F ,0x428 ,0x0000000A ,0x429 ,0x00000010 ,0x430 ,0x00000000 ,
@@ -2485,7 +2666,7 @@ u32 RTL8821AE_AGC_TAB_ARRAY[] = {0x81C ,0xA6360001 ,0x81C ,0xA5380001 ,0x81C ,0xA43A0001 , -0x81C ,0xA33C0001 , +0x81C ,0x683C0001 ,0x81C ,0x673E0001 ,0x81C ,0x66400001 , 0x81C, 0x65420001,
@@ -2519,7 +2700,66 @@ u32 RTL8821AE_AGC_TAB_ARRAY[] = {0x81C ,0x017A0001 ,0x81C ,0x017C0001 ,0x81C ,0x017E0001 , -0xFF0F02C0 ,0xABCD , +0x8000020c ,0x00000000 ,0x40000000 ,0x00000000 , +0x81C ,0xFB000101 , +0x81C ,0xFA020101 , +0x81C ,0xF9040101 , +0x81C ,0xF8060101 , +0x81C ,0xF7080101 , +0x81C ,0xF60A0101 , +0x81C ,0xF50C0101 , +0x81C ,0xF40E0101 , +0x81C ,0xF3100101 , +0x81C ,0xF2120101 , +0x81C ,0xF1140101 , +0x81C ,0xF0160101 , +0x81C ,0xEF180101 , +0x81C ,0xEE1A0101 , +0x81C ,0xED1C0101 , +0x81C ,0xEC1E0101 , +0x81C ,0xEB200101 , +0x81C ,0xEA220101 , +0x81C ,0xE9240101 , +0x81C ,0xE8260101 , +0x81C ,0xE7280101 , +0x81C ,0xE62A0101 , +0x81C ,0xE52C0101 , +0x81C ,0xE42E0101 , +0x81C ,0xE3300101 , +0x81C ,0xA5320101 , +0x81C ,0xA4340101 , +0x81C ,0xA3360101 , +0x81C ,0x87380101 , +0x81C ,0x863A0101 , +0x81C ,0x853C0101 , +0x81C ,0x843E0101 , +0x81C ,0x69400101 , +0x81C ,0x68420101 , +0x81C ,0x67440101 , +0x81C ,0x66460101 , +0x81C ,0x49480101 , +0x81C ,0x484A0101 , +0x81C ,0x474C0101 , +0x81C ,0x2A4E0101 , +0x81C ,0x29500101 , +0x81C ,0x28520101 , +0x81C ,0x27540101 , +0x81C ,0x26560101 , +0x81C ,0x25580101 , +0x81C ,0x245A0101 , +0x81C ,0x235C0101 , +0x81C ,0x055E0101 , +0x81C ,0x04600101 , +0x81C ,0x03620101 , +0x81C ,0x02640101 , +0x81C ,0x01660101 , +0x81C ,0x01680101 , +0x81C ,0x016A0101 , +0x81C ,0x016C0101 , +0x81C ,0x016E0101 , +0x81C ,0x01700101 , +0x81C ,0x01720101 , +0x9000040c ,0x00000000 ,0x40000000 ,0x00000000 ,0x81C ,0xFB000101 ,0x81C ,0xFA020101 , 0x81C, 0xF9040101,
@@ -2578,7 +2818,7 @@ u32 RTL8821AE_AGC_TAB_ARRAY[] = {0x81C ,0x016E0101 ,0x81C ,0x01700101 ,0x81C ,0x01720101 , -0xCDCDCDCD ,0xCDCD , +0xA0000000 ,0x00000000 ,0x81C ,0xFF000101 ,0x81C ,0xFF020101 , 0x81C, 0xFE040101,
@@ -2637,7 +2877,7 @@ u32 RTL8821AE_AGC_TAB_ARRAY[] = {0x81C ,0x046E0101 ,0x81C ,0x03700101 ,0x81C ,0x02720101 , -0xFF0F02C0 ,0xDEAD , +0xB0000000 ,0x00000000 ,0x81C ,0x01740101 ,0x81C ,0x01760101 , 0x81C, 0x01780101,
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 212/244 i2c: sh7760: fix IRQ error path
In reply to Greg Kroah-HartmanFrom: Sergey Shtylyov <[email protected]>
[ Upstream commit 92dfb27240fea2776f61c5422472cb6defca7767 ]
While adding the invalid IRQ check after calling platform_get_irq(), I managed to overlook that the driver has a complex error path in its probe() method, thus a simple *return* couldn't be used. Use a proper *goto* instead!
--- drivers/i2c/busses/i2c-sh7760.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i2c/busses/i2c-sh7760.c +1 -1
@@ -473,7 +473,7 @@ static int sh7760_i2c_probe(struct platform_device *pdev) ret =platform_get_irq (pdev,0 );if (ret <0 ) -return ret; + goto out3; id->irq = ret; id->adap.nr = pdev->id;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 213/244 mwl8k: Fix a double Free in mwl8k_probe_hw
In reply to Greg Kroah-HartmanFrom: Lv Yunlong <[email protected]>
[ Upstream commit a8e083ee8e2a6c94c29733835adae8bf5b832748 ]
In mwl8k_probe_hw, hw->priv->txq is freed at the first time by dma_free_coherent() in the call chain:
if(!priv->ap_fw)->mwl8k_init_txqs(hw)->mwl8k_txq_init(hw, i).
Then in err_free_queues of mwl8k_probe_hw, hw->priv->txq is freed at the second time by mwl8k_txq_deinit(hw, i)->dma_free_coherent().
My patch set txq->txd to NULL after the first free to avoid the double free.
--- drivers/net/wireless/marvell/mwl8k.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/marvell/mwl8k.c +1 -0
@@ -1469,6 +1469,7 @@ static int mwl8k_txq_init(struct ieee80211_hw *hw, int index) txq->skb =kcalloc (MWL8K_TX_DESCS ,sizeof (*txq->skb),GFP_KERNEL );if (txq->skb ==NULL ) {pci_free_consistent (priv->pdev, size, txq->txd, txq->txd_dma); + txq->txd =NULL ;return -ENOMEM ; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 214/244 vsock/vmci: log once the failed queue pair allocation
In reply to Greg Kroah-HartmanFrom: Stefano Garzarella <[email protected]>
[ Upstream commit e16edc99d658cd41c60a44cc14d170697aa3271f ]
VMCI feature is not supported in conjunction with the vSphere Fault Tolerance (FT) feature.
VMware Tools can repeatedly try to create a vsock connection. If FT is enabled the kernel logs is flooded with the following messages:
qp_alloc_hypercall result = -20
Could not attach to queue pair with -20
"qp_alloc_hypercall result = -20" was hidden by commit e8266c4c3307 ("VMCI: Stop log spew when qp allocation isn't possible"), but "Could not attach to queue pair with -20" is still there flooding the log.
Since the error message can be useful in some cases, print it only once.
--- net/vmw_vsock/vmci_transport.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
net/vmw_vsock/vmci_transport.c +1 -2
@@ -576,8 +576,7 @@ vmci_transport_queue_pair_alloc(struct vmci_qp **qpair, peer, flags, VMCI_NO_PRIVILEGE_FLAGS); out:if (err <0 ) { -pr_err ("Could not attach to queue pair with %d\n" , - err); +pr_err_once ("Could not attach to queue pair with %d\n" , err); err =vmci_transport_error_to_vsock_error (err); }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 215/244 gro: fix napi_gro_frags() Fast GRO breakage due to IP alignment check
In reply to Greg Kroah-HartmanFrom: Alexander Lobakin <[email protected]>
[ Upstream commit 7ad18ff6449cbd6beb26b53128ddf56d2685aa93 ]
Commit 38ec4944b593 ("gro: ensure frag0 meets IP header alignment") did the right thing, but missed the fact that napi_gro_frags() logics calls for skb_gro_reset_offset() *before* pulling Ethernet header to the skb linear space.
That said, the introduced check for frag0 address being aligned to 4 always fails for it as Ethernet header is obviously 14 bytes long, and in case with NET_IP_ALIGN its start is not aligned to 4.
Fix this by adding @nhoff argument to skb_gro_reset_offset() which tells if an IP header is placed right at the start of frag0 or not. This restores Fast GRO for napi_gro_frags() that became very slow after the mentioned commit, and preserves the introduced check to avoid silent unaligned accesses.
Quoted 1 line
From v1 [0]:
- inline tiny skb_gro_reset_offset() to let the code be optimized more efficively (esp. for the !NET_IP_ALIGN case) (Eric);
- pull in Reviewed-by from Eric.
[0] https://lore.kernel.org/netdev/[email protected]
--- net/core/dev.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
net/core/dev.c +4 -4
@@ -5395,7 +5395,7 @@ static struct list_head *gro_list_prepare(struct napi_struct *napi,return head; } -static void skb_gro_reset_offset (struct sk_buff *skb) +static inline void skb_gro_reset_offset (struct sk_buff *skb,u32 nhoff) {const struct skb_shared_info *pinfo =skb_shinfo (skb);const skb_frag_t *frag0 = &pinfo->frags[0 ];
@@ -5407,7 +5407,7 @@ static void skb_gro_reset_offset(struct sk_buff *skb)if (skb_mac_header (skb) ==skb_tail_pointer (skb) && pinfo->nr_frags && !PageHighMem (skb_frag_page (frag0)) && - (!NET_IP_ALIGN || !(skb_frag_off (frag0) &3 ))) { + (!NET_IP_ALIGN || !((skb_frag_off (frag0) + nhoff) &3 ))) {NAPI_GRO_CB (skb)->frag0 =skb_frag_address (frag0); NAPI_GRO_CB(skb)->frag0_len = min_t(unsigned int, skb_frag_size(frag0),
@@ -5640,7 +5640,7 @@ gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)skb_mark_napi_id (skb, napi);trace_napi_gro_receive_entry (skb); -skb_gro_reset_offset (skb); +skb_gro_reset_offset (skb,0 ); ret =napi_skb_finish (napi, skb,dev_gro_receive (napi, skb));trace_napi_gro_receive_exit (ret);
@@ -5733,7 +5733,7 @@ static struct sk_buff *napi_frags_skb(struct napi_struct *napi) napi->skb =NULL ;skb_reset_mac_header (skb); -skb_gro_reset_offset (skb); +skb_gro_reset_offset (skb, hlen);if (unlikely (skb_gro_header_hard (skb, hlen))) { eth =skb_gro_header_slow (skb, hlen,0 );
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 216/244 RDMA/cxgb4: add missing qpid increment
In reply to Greg Kroah-HartmanFrom: Potnuri Bharat Teja <[email protected]>
[ Upstream commit 3a6684385928d00b29acac7658a5ae1f2a44494c ]
missing qpid increment leads to skipping few qpids while allocating QP. This eventually leads to adapter running out of qpids after establishing fewer connections than it actually supports.
Current patch increments the qpid correctly.
--- drivers/infiniband/hw/cxgb4/resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/hw/cxgb4/resource.c +1 -1
@@ -216,7 +216,7 @@ u32 c4iw_get_qpid(struct c4iw_rdev *rdev, struct c4iw_dev_ucontext *uctx) goto out; entry->qid = qid;list_add_tail (&entry->entry, &uctx->cqids); -for (i = qid; i & rdev->qpmask; i++) { +for (i = qid +1 ; i & rdev->qpmask; i++) { entry =kmalloc (sizeof (*entry),GFP_KERNEL );if (!entry) goto out;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 217/244 RDMA/i40iw: Fix error unwinding when i40iw_hmc_sd_one fails
In reply to Greg Kroah-HartmanFrom: Sindhu Devale <[email protected]>
[ Upstream commit 783a11bf2400e5d5c42a943c3083dc0330751842 ]
When i40iw_hmc_sd_one fails, chunk is freed without the deletion of chunk entry in the PBLE info list.
Fix it by adding the chunk entry to the PBLE info list only after successful addition of SD in i40iw_hmc_sd_one.
This fixes a static checker warning reported here:
https://lore.kernel.org/linux-rdma/YHV4CFXzqTm23AOZ@mwanda/
--- drivers/infiniband/hw/i40iw/i40iw_pble.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/infiniband/hw/i40iw/i40iw_pble.c +2 -4
@@ -392,12 +392,9 @@ static enum i40iw_status_code add_pble_pool(struct i40iw_sc_dev *dev,i40iw_debug (dev,I40IW_DEBUG_PBLE ,"next_fpm_addr = %llx chunk_size[%u] = 0x%x\n" , pble_rsrc->next_fpm_addr, chunk->size, chunk->size); pble_rsrc->unallocated_pble -= (chunk->size >>3 ); -list_add (&chunk->list, &pble_rsrc->pinfo.clist); sd_reg_val = (sd_entry_type ==I40IW_SD_TYPE_PAGED ) ? sd_entry->u.pd_table.pd_page_addr.pa : sd_entry->u.bp.addr.pa; -if (sd_entry->valid) -return 0 ; -if (dev->is_pf) { +if (dev->is_pf && !sd_entry->valid) { ret_code =i40iw_hmc_sd_one (dev, hmc_info->hmc_fn_id, sd_reg_val, idx->sd_idx, sd_entry->entry_type, true);
@@ -408,6 +405,7 @@ static enum i40iw_status_code add_pble_pool(struct i40iw_sc_dev *dev, } sd_entry->valid = true; +list_add (&chunk->list, &pble_rsrc->pinfo.clist);return 0 ; error:kfree (chunk);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 218/244 ALSA: usb: midi: dont return -ENOMEM when usb_urb_ep_type_check fails
In reply to Greg Kroah-HartmanFrom: Colin Ian King <[email protected]>
[ Upstream commit cfd577acb769301b19c31361d45ae1f145318b7a ]
Currently when the call to usb_urb_ep_type_check fails (returning -EINVAL) the error return path returns -ENOMEM via the exit label "error". Other uses of the same error exit label set the err variable to -ENOMEM but this is not being used. I believe the original intent was for the error exit path to return the value in err rather than the hard coded -ENOMEM, so return this rather than the hard coded -ENOMEM.
Addresses-Coverity: ("Unused value")
--- sound/usb/midi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/usb/midi.c +1 -1
@@ -1332,7 +1332,7 @@ static int snd_usbmidi_in_endpoint_create(struct snd_usb_midi *umidi, error:snd_usbmidi_in_endpoint_delete (ep); -return -ENOMEM ; +return err; }/*
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 219/244 net: davinci_emac: Fix incorrect masking of tx and rx error channel
In reply to Greg Kroah-HartmanFrom: Colin Ian King <[email protected]>
[ Upstream commit d83b8aa5207d81f9f6daec9888390f079cc5db3f ]
The bit-masks used for the TXERRCH and RXERRCH (tx and rx error channels) are incorrect and always lead to a zero result. The mask values are currently the incorrect post-right shifted values, fix this by setting them to the currect values.
(I double checked these against the TMS320TCI6482 data sheet, section 5.30, page 127 to ensure I had the correct mask values for the TXERRCH and RXERRCH fields in the MACSTATUS register).
Addresses-Coverity: ("Operands don't affect result")
--- drivers/net/ethernet/ti/davinci_emac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/ti/davinci_emac.c +2 -2
@@ -169,11 +169,11 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";/* EMAC mac_status register */ #define EMAC_MACSTATUS_TXERRCODE_MASK (0xF00000)#define EMAC_MACSTATUS_TXERRCODE_SHIFT (20) -#define EMAC_MACSTATUS_TXERRCH_MASK (0x7) +#define EMAC_MACSTATUS_TXERRCH_MASK (0x70000)#define EMAC_MACSTATUS_TXERRCH_SHIFT (16)#define EMAC_MACSTATUS_RXERRCODE_MASK (0xF000)#define EMAC_MACSTATUS_RXERRCODE_SHIFT (12) -#define EMAC_MACSTATUS_RXERRCH_MASK (0x7) +#define EMAC_MACSTATUS_RXERRCH_MASK (0x700)#define EMAC_MACSTATUS_RXERRCH_SHIFT (8)/* EMAC RX register masks */
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 220/244 net: renesas: ravb: Fix a stuck issue when a lot of frames are received
In reply to Greg Kroah-HartmanFrom: Yoshihiro Shimoda <[email protected]>
[ Upstream commit 5718458b092bf6bf4482c5df32affba3c3259517 ]
When a lot of frames were received in the short term, the driver caused a stuck of receiving until a new frame was received. For example, the following command from other device could cause this issue.
$ sudo ping -f -l 1000 -c 1000 <this driver's ipaddress>
The previous code always cleared the interrupt flag of RX but checks the interrupt flags in ravb_poll(). So, ravb_poll() could not call ravb_rx() in the next time until a new RX frame was received if ravb_rx() returned true. To fix the issue, always calls ravb_rx() regardless the interrupt flags condition.
--- drivers/net/ethernet/renesas/ravb_main.c | 35 ++++++++---------------- 1 file changed, 12 insertions(+), 23 deletions(-)
drivers/net/ethernet/renesas/ravb_main.c +12 -23
@@ -911,31 +911,20 @@ static int ravb_poll(struct napi_struct *napi, int budget)int q = napi - priv->napi;int mask =BIT (q);int quota = budget; -u32 ris0, tis; -for (;;) { - tis =ravb_read (ndev,TIS ); - ris0 =ravb_read (ndev,RIS0 ); -if (!((ris0 & mask) || (tis & mask))) -break ; +/* Processing RX Descriptor Ring */ +/* Clear RX interrupt */ +ravb_write (ndev, ~(mask |RIS0_RESERVED ),RIS0 ); +if (ravb_rx (ndev, "a, q)) + goto out; -/* Processing RX Descriptor Ring */ -if (ris0 & mask) { -/* Clear RX interrupt */ -ravb_write (ndev, ~(mask |RIS0_RESERVED ),RIS0 ); -if (ravb_rx (ndev, "a, q)) - goto out; - } -/* Processing TX Descriptor Ring */ -if (tis & mask) { -spin_lock_irqsave (&priv->lock, flags); -/* Clear TX interrupt */ -ravb_write (ndev, ~(mask |TIS_RESERVED ),TIS ); -ravb_tx_free (ndev, q, true); -netif_wake_subqueue (ndev, q); -spin_unlock_irqrestore (&priv->lock, flags); - } - } +/* Processing RX Descriptor Ring */ +spin_lock_irqsave (&priv->lock, flags); +/* Clear TX interrupt */ +ravb_write (ndev, ~(mask |TIS_RESERVED ),TIS ); +ravb_tx_free (ndev, q, true); +netif_wake_subqueue (ndev, q); +spin_unlock_irqrestore (&priv->lock, flags);napi_complete (napi);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 221/244 net: phy: intel-xway: enable integrated led functions
In reply to Greg Kroah-HartmanFrom: Martin Schiller <[email protected]>
[ Upstream commit 357a07c26697a770d39d28b6b111f978deb4017d ]
The Intel xway phys offer the possibility to deactivate the integrated LED function and to control the LEDs manually.
If this was set by the bootloader, it must be ensured that the integrated LED function is enabled for all LEDs when loading the driver.
Before commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") the LEDs were enabled by a soft-reset of the PHY (using genphy_soft_reset). Initialize the XWAY_MDIO_LED with it's default value (which is applied during a soft reset) instead of adding back the soft reset. This brings back the default LED configuration while still preventing an excessive amount of soft resets.
--- drivers/net/phy/intel-xway.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
drivers/net/phy/intel-xway.c +21 -0
@@ -11,6 +11,18 @@#define XWAY_MDIO_IMASK 0x19/* interrupt mask */ #define XWAY_MDIO_ISTAT 0x1A/* interrupt status */ +#define XWAY_MDIO_LED 0x1B/* led control */ + +/* bit 15:12 are reserved */ +#define XWAY_MDIO_LED_LED3_EN BIT(11)/* Enable the integrated function of LED3 */ +#define XWAY_MDIO_LED_LED2_EN BIT(10)/* Enable the integrated function of LED2 */ +#define XWAY_MDIO_LED_LED1_EN BIT(9)/* Enable the integrated function of LED1 */ +#define XWAY_MDIO_LED_LED0_EN BIT(8)/* Enable the integrated function of LED0 */ +/* bit 7:4 are reserved */ +#define XWAY_MDIO_LED_LED3_DA BIT(3)/* Direct Access to LED3 */ +#define XWAY_MDIO_LED_LED2_DA BIT(2)/* Direct Access to LED2 */ +#define XWAY_MDIO_LED_LED1_DA BIT(1)/* Direct Access to LED1 */ +#define XWAY_MDIO_LED_LED0_DA BIT(0)/* Direct Access to LED0 */ #define XWAY_MDIO_INIT_WOL BIT(15)/* Wake-On-LAN */ #define XWAY_MDIO_INIT_MSRE BIT(14)
@@ -159,6 +171,15 @@ static int xway_gphy_config_init(struct phy_device *phydev)/* Clear all pending interrupts */ phy_read (phydev,XWAY_MDIO_ISTAT ); +/* Ensure that integrated led function is enabled for all leds */ + err =phy_write (phydev,XWAY_MDIO_LED , +XWAY_MDIO_LED_LED0_EN | +XWAY_MDIO_LED_LED1_EN | +XWAY_MDIO_LED_LED2_EN | +XWAY_MDIO_LED_LED3_EN ); +if (err) +return err; + phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDCH, XWAY_MMD_LEDCH_NACS_NONE | XWAY_MMD_LEDCH_SBF_F02HZ |
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 222/244 ath9k: Fix error check in ath9k_hw_read_revisions() for PCI devices
In reply to Greg Kroah-HartmanFrom: Toke Høiland-Jørgensen <[email protected]>
[ Upstream commit 7dd9a40fd6e0d0f1fd8e1931c007e080801dfdce ]
When the error check in ath9k_hw_read_revisions() was added, it checked for -EIO which is what ath9k_regread() in the ath9k_htc driver uses. However, for plain ath9k, the register read function uses ioread32(), which just returns -1 on error. So if such a read fails, it still gets passed through and ends up as a weird mac revision in the log output.
Fix this by changing ath9k_regread() to return -1 on error like ioread32() does, and fix the error check to look for that instead of -EIO.
--- drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +- drivers/net/wireless/ath/ath9k/hw.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/ath/ath9k/htc_drv_init.c +1 -1
@@ -246,7 +246,7 @@ static unsigned int ath9k_regread(void *hw_priv, u32 reg_offset)if (unlikely (r)) {ath_dbg (common,WMI ,"REGISTER READ FAILED: (0x%04x, %d)\n" , reg_offset, r); -return -EIO ; +return -1 ; }return be32_to_cpu (val);
drivers/net/wireless/ath/ath9k/hw.c +1 -1
@@ -287,7 +287,7 @@ static bool ath9k_hw_read_revisions(struct ath_hw *ah) srev =REG_READ (ah,AR_SREV ); -if (srev == -EIO ) { +if (srev ==-1 ) {ath_err (ath9k_hw_common (ah),"Failed to read SREV register" );return false;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 223/244 ath10k: Fix ath10k_wmi_tlv_op_pull_peer_stats_info() unlock without lock
In reply to Greg Kroah-HartmanFrom: Shuah Khan <[email protected]>
[ Upstream commit eaaf52e4b866f265eb791897d622961293fd48c1 ]
ath10k_wmi_tlv_op_pull_peer_stats_info() could try to unlock RCU lock winthout locking it first when peer reason doesn't match the valid cases for this function.
Add a default case to return without unlocking.
--- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/wireless/ath/ath10k/wmi-tlv.c +3 -0
@@ -461,6 +461,9 @@ static void ath10k_wmi_event_tdls_peer(struct ath10k *ar, struct sk_buff *skb)GFP_ATOMIC );break ; +default : +kfree (tb); +return ; } exit:
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 224/244 powerpc/52xx: Fix an invalid ASM expression (addi used instead of add)
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
[ Upstream commit 8a87a507714386efc39c3ae6fa24d4f79846b522 ]
AS arch/powerpc/platforms/52xx/lite5200_sleep.oarch/powerpc/platforms/52xx/lite5200_sleep.S: Assembler messages:arch/powerpc/platforms/52xx/lite5200_sleep.S:184: Warning: invalid register expression
In the following code, 'addi' is wrong, has to be 'add'
/* local udelay in sram is needed */ udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */ mullw r12, r12, r11 mftb r13 /* start */ addi r12, r13, r12 /* end */
--- arch/powerpc/platforms/52xx/lite5200_sleep.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/platforms/52xx/lite5200_sleep.S +1 -1
@@ -181,7 +181,7 @@ sram_code: udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */ mullw r12, r12, r11 mftb r13 /* start */ - addi r12, r13, r12 /* end */ + add r12, r13, r12 /* end */ 1: mftb r13 /* current */ cmp cr0, r13, r12
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 225/244 bnxt_en: fix ternary sign extension bug in bnxt_show_temp()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit 27537929f30d3136a71ef29db56127a33c92dad7 ]
The problem is that bnxt_show_temp() returns long but "rc" is an int and "len" is a u32. With ternary operations the type promotion is quite tricky. The negative "rc" is first promoted to u32 and then to long so it ends up being a high positive value instead of a a negative as we intended.
Fix this by removing the ternary.
--- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/broadcom/bnxt/bnxt.c +3 -1
@@ -8954,7 +8954,9 @@ static ssize_t bnxt_show_temp(struct device *dev,if (!rc) len =sprintf (buf,"%u\n" , resp->temp *1000 );/* display millidegree */ mutex_unlock (&bp->hwrm_cmd_lock); -return rc ?: len; +if (rc) +return rc; +return len; } static SENSOR_DEVICE_ATTR(temp1_input, 0444, bnxt_show_temp, NULL, 0);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 226/244 ARM: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins for RTL8211E
In reply to Greg Kroah-HartmanFrom: Kunihiko Hayashi <[email protected]>
[ Upstream commit 9ba585cc5b56ea14a453ba6be9bdb984ed33471a ]
UniPhier PXs2 boards have RTL8211E ethernet phy, and the phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY pins.
After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the delays are working correctly, however, "rgmii" means no delay and the phy doesn't work. So need to set the phy-mode to "rgmii-id" to show that RX/TX delays are enabled.
--- arch/arm/boot/dts/uniphier-pxs2.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/uniphier-pxs2.dtsi +1 -1
@@ -571,7 +571,7 @@ clocks = <&sys_clk 6>; reset-names = "ether"; resets = <&sys_rst 6>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; local-mac-address = [00 00 00 00 00 00]; socionext,syscon-phy-mode = <&soc_glue 0>;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 227/244 arm64: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins for RTL8211E
In reply to Greg Kroah-HartmanFrom: Kunihiko Hayashi <[email protected]>
[ Upstream commit dcabb06bf127b3e0d3fbc94a2b65dd56c2725851 ]
UniPhier LD20 and PXs3 boards have RTL8211E ethernet phy, and the phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY pins.
After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the delays are working correctly, however, "rgmii" means no delay and the phy doesn't work. So need to set the phy-mode to "rgmii-id" to show that RX/TX delays are enabled.
--- arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 +- arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi +1 -1
@@ -718,7 +718,7 @@ clocks = <&sys_clk 6>; reset-names = "ether"; resets = <&sys_rst 6>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; local-mac-address = [00 00 00 00 00 00]; socionext,syscon-phy-mode = <&soc_glue 0>;
arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi +2 -2
@@ -509,7 +509,7 @@ clocks = <&sys_clk 6>; reset-names = "ether"; resets = <&sys_rst 6>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; local-mac-address = [00 00 00 00 00 00]; socionext,syscon-phy-mode = <&soc_glue 0>;
@@ -530,7 +530,7 @@ clocks = <&sys_clk 7>; reset-names = "ether"; resets = <&sys_rst 7>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; local-mac-address = [00 00 00 00 00 00]; socionext,syscon-phy-mode = <&soc_glue 1>;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 228/244 net: geneve: modify IP header check in geneve6_xmit_skb and geneve_xmit_skb
In reply to Greg Kroah-HartmanFrom: Phillip Potter <[email protected]>
[ Upstream commit d13f048dd40e8577260cd43faea8ec9b77520197 ]
Modify the header size check in geneve6_xmit_skb and geneve_xmit_skb to use pskb_inet_may_pull rather than pskb_network_may_pull. This fixes two kernel selftest failures introduced by the commit introducing the checks:
IPv4 over geneve6: PMTU exceptions
IPv4 over geneve6: PMTU exceptions - nexthop objects
It does this by correctly accounting for the fact that IPv4 packets may transit over geneve IPv6 tunnels (and vice versa), and still fixes the uninit-value bug fixed by the original commit.
--- drivers/net/geneve.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/geneve.c +2 -2
@@ -891,7 +891,7 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,__be16 sport;int err; -if (!pskb_network_may_pull (skb,sizeof (struct iphdr ))) +if (!pskb_inet_may_pull (skb))return -EINVAL ; sport =udp_flow_src_port (geneve->net, skb,1 ,USHRT_MAX , true);
@@ -957,7 +957,7 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,__be16 sport;int err; -if (!pskb_network_may_pull (skb,sizeof (struct ipv6hdr ))) +if (!pskb_inet_may_pull (skb))return -EINVAL ; sport =udp_flow_src_port (geneve->net, skb,1 ,USHRT_MAX , true);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 229/244 selftests: net: mirror_gre_vlan_bridge_1q: Make an FDB entry static
In reply to Greg Kroah-HartmanFrom: Petr Machata <[email protected]>
[ Upstream commit c8d0260cdd96fdccdef0509c4160e28a1012a5d7 ]
The FDB roaming test installs a destination MAC address on the wrong interface of an FDB database and tests whether the mirroring fails, because packets are sent to the wrong port. The test by mistake installs the FDB entry as local. This worked previously, because drivers were notified of local FDB entries in the same way as of static entries. However that has been fixed in the commit 6ab4c3117aec ("net: bridge: don't notify switchdev for local FDB addresses"), and local entries are not notified anymore. As a result, the HW is not reconfigured for the FDB roam, and mirroring keeps working, failing the test.
To fix the issue, mark the FDB entry as static.
--- .../selftests/net/forwarding/mirror_gre_vlan_bridge_1q.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/net/forwarding/mirror_gre_vlan_bridge_1q.sh +1 -1
@@ -271,7 +271,7 @@ test_span_gre_fdb_roaming() while ((RET == 0)); do bridge fdb del dev $swp3 $h3mac vlan 555 master 2>/dev/null - bridge fdb add dev $swp2 $h3mac vlan 555 master + bridge fdb add dev $swp2 $h3mac vlan 555 master static sleep 1 fail_test_span_gre_dir $tundev ingress
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 230/244 bnxt_en: Fix RX consumer index logic in the error path.
In reply to Greg Kroah-HartmanFrom: Michael Chan <[email protected]>
[ Upstream commit bbd6f0a948139970f4a615dff189d9a503681a39 ]
In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxt_discard_rx() is not correct. We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this:
#0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e
#3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978
#4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5
[exception RIP: bnxt_rx_pkt+237]
RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213
RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000
RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000
RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d
R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0
R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018--- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/broadcom/bnxt/bnxt.c +4 -2
@@ -1728,12 +1728,14 @@ static int bnxt_rx_pkt(struct bnxt *bp, struct bnxt_cp_ring_info *cpr, cons = rxcmp->rx_cmp_opaque;if (unlikely (cons != rxr->rx_next_cons)) { -int rc1 =bnxt_discard_rx (bp, cpr, raw_cons, rxcmp); +int rc1 =bnxt_discard_rx (bp, cpr, &tmp_raw_cons, rxcmp);netdev_warn (bp->dev,"RX cons %x != expected cons %x\n" , cons, rxr->rx_next_cons);bnxt_sched_reset (bp, rxr); -return rc1; +if (rc1) +return rc1; + goto next_rx_no_prod_no_len; } rx_buf = &rxr->rx_buf_ring[cons]; data = rx_buf->data;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 231/244 net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send
In reply to Greg Kroah-HartmanFrom: Lv Yunlong <[email protected]>
[ Upstream commit 6d72e7c767acbbdd44ebc7d89c6690b405b32b57 ]
In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).
If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().
But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len).
As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later.
--- drivers/net/ethernet/qualcomm/emac/emac-mac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/qualcomm/emac/emac-mac.c +3 -1
@@ -1439,6 +1439,7 @@ int emac_mac_tx_buf_send(struct emac_adapter *adpt, struct emac_tx_queue *tx_q, {struct emac_tpd tpd;u32 prod_idx; +int len;memset (&tpd,0 ,sizeof (tpd));
@@ -1458,9 +1459,10 @@ int emac_mac_tx_buf_send(struct emac_adapter *adpt, struct emac_tx_queue *tx_q,if (skb_network_offset (skb) !=ETH_HLEN )TPD_TYP_SET (&tpd,1 ); + len = skb->len;emac_tx_fill_tpd (adpt, tx_q, skb, &tpd); -netdev_sent_queue (adpt->netdev, skb->len); +netdev_sent_queue (adpt->netdev, len);/* Make sure the are enough free descriptors to hold one * maximum-sized SKB. We need one desc for each fragment,
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 232/244 RDMA/siw: Fix a use after free in siw_alloc_mr
In reply to Greg Kroah-HartmanFrom: Lv Yunlong <[email protected]>
[ Upstream commit 3093ee182f01689b89e9f8797b321603e5de4f63 ]
Our code analyzer reported a UAF.
In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of siw_mr_add_mem(), mem is assigned to mr->mem and then mem is freed via kfree(mem) if xa_alloc_cyclic() failed. Here, mr->mem still point to a freed object. After, the execution continue up to the err_out branch of siw_alloc_mr, and the freed mr->mem is used in siw_mr_drop_mem(mr).
My patch moves "mr->mem = mem" behind the if (xa_alloc_cyclic(..)<0) {} section, to avoid the uaf.
--- drivers/infiniband/sw/siw/siw_mem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/sw/siw/siw_mem.c +2 -2
@@ -106,8 +106,6 @@ int siw_mr_add_mem(struct siw_mr *mr, struct ib_pd *pd, void *mem_obj, mem->perms = rights &IWARP_ACCESS_MASK ;kref_init (&mem->ref); - mr->mem = mem; -get_random_bytes (&next,4 ); next &=0x00ffffff ;
@@ -116,6 +114,8 @@ int siw_mr_add_mem(struct siw_mr *mr, struct ib_pd *pd, void *mem_obj,kfree (mem);return -ENOMEM ; } + + mr->mem = mem;/* Set the STag index part */ mem->stag = id <<8 ; mr->base_mr.lkey = mr->base_mr.rkey = mem->stag;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 233/244 RDMA/bnxt_re: Fix a double free in bnxt_qplib_alloc_res
In reply to Greg Kroah-HartmanFrom: Lv Yunlong <[email protected]>
[ Upstream commit 34b39efa5ae82fc0ad0acc27653c12a56328dbbe ]
In bnxt_qplib_alloc_res, it calls bnxt_qplib_alloc_dpi_tbl(). Inside bnxt_qplib_alloc_dpi_tbl, dpit->dbr_bar_reg_iomem is freed via pci_iounmap() in unmap_io error branch. After the callee returns err code, bnxt_qplib_alloc_res calls bnxt_qplib_free_res()->bnxt_qplib_free_dpi_tbl() in the fail branch. Then dpit->dbr_bar_reg_iomem is freed in the second time by pci_iounmap().
My patch set dpit->dbr_bar_reg_iomem to NULL after it is freed by pci_iounmap() in the first time, to avoid the double free.
--- drivers/infiniband/hw/bnxt_re/qplib_res.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/hw/bnxt_re/qplib_res.c +1 -0
@@ -736,6 +736,7 @@ static int bnxt_qplib_alloc_dpi_tbl(struct bnxt_qplib_res *res, unmap_io:pci_iounmap (res->pdev, dpit->dbr_bar_reg_iomem); + dpit->dbr_bar_reg_iomem =NULL ;return -ENOMEM ; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 234/244 net: bridge: mcast: fix broken length + header check for MRDv6 Adv.
In reply to Greg Kroah-HartmanFrom: Linus Lüssing <[email protected]>
[ Upstream commit 99014088156cd78867d19514a0bc771c4b86b93b ]
The IPv6 Multicast Router Advertisements parsing has the following two issues:
For one thing, ICMPv6 MRD Advertisements are smaller than ICMPv6 MLD messages (ICMPv6 MRD Adv.: 8 bytes vs. ICMPv6 MLDv1/2: >= 24 bytes, assuming MLDv2 Reports with at least one multicast address entry). When ipv6_mc_check_mld_msg() tries to parse an Multicast Router Advertisement its MLD length check will fail - and it will wrongly return -EINVAL, even if we have a valid MRD Advertisement. With the returned -EINVAL the bridge code will assume a broken packet and will wrongly discard it, potentially leading to multicast packet loss towards multicast routers.
The second issue is the MRD header parsing in br_ip6_multicast_mrd_rcv(): It wrongly checks for an ICMPv6 header immediately after the IPv6 header (IPv6 next header type). However according to RFC4286, section 2 all MRD messages contain a Router Alert option (just like MLD). So instead there is an IPv6 Hop-by-Hop option for the Router Alert between the IPv6 and ICMPv6 header, again leading to the bridge wrongly discarding Multicast Router Advertisements.
To fix these two issues, introduce a new return value -ENODATA to ipv6_mc_check_mld() to indicate a valid ICMPv6 packet with a hop-by-hop option which is not an MLD but potentially an MRD packet. This also simplifies further parsing in the bridge code, as ipv6_mc_check_mld() already fully checks the ICMPv6 header and hop-by-hop option.
These issues were found and fixed with the help of the mrdisc tool
(https://github.com/troglobit/mrdisc).
--- include/net/addrconf.h | 1 - net/bridge/br_multicast.c | 33 ++++++++------------------------- net/ipv6/mcast_snoop.c | 12 +++++++----- 3 files changed, 15 insertions(+), 31 deletions(-)
include/net/addrconf.h +0 -1
@@ -229,7 +229,6 @@ void ipv6_mc_unmap(struct inet6_dev *idev);void ipv6_mc_remap (struct inet6_dev *idev);void ipv6_mc_init_dev (struct inet6_dev *idev);void ipv6_mc_destroy_dev (struct inet6_dev *idev); -int ipv6_mc_check_icmpv6 (struct sk_buff *skb);int ipv6_mc_check_mld (struct sk_buff *skb);void addrconf_dad_failure (struct sk_buff *skb,struct inet6_ifaddr *ifp);
net/bridge/br_multicast.c +8 -25
@@ -1647,25 +1647,14 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br, }#if IS_ENABLED (CONFIG_IPV6 ) -static int br_ip6_multicast_mrd_rcv (struct net_bridge *br, -struct net_bridge_port *port, -struct sk_buff *skb) +static void br_ip6_multicast_mrd_rcv (struct net_bridge *br, +struct net_bridge_port *port, +struct sk_buff *skb) { -int ret; - -if (ipv6_hdr (skb)->nexthdr !=IPPROTO_ICMPV6 ) -return -ENOMSG ; - - ret =ipv6_mc_check_icmpv6 (skb); -if (ret <0 ) -return ret; -if (icmp6_hdr (skb)->icmp6_type !=ICMPV6_MRDISC_ADV ) -return -ENOMSG ; +return ;br_multicast_mark_router (br, port); - -return 0 ; } static int br_multicast_ipv6_rcv(struct net_bridge *br,
@@ -1679,18 +1668,12 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br, err =ipv6_mc_check_mld (skb); -if (err == -ENOMSG ) { +if (err == -ENOMSG || err == -ENODATA ) {if (!ipv6_addr_is_ll_all_nodes (&ipv6_hdr (skb)->daddr))BR_INPUT_SKB_CB (skb)->mrouters_only =1 ; - -if (ipv6_addr_is_all_snoopers (&ipv6_hdr (skb)->daddr)) { - err =br_ip6_multicast_mrd_rcv (br, port, skb); - -if (err <0 && err != -ENOMSG ) { -br_multicast_err_count (br, port, skb->protocol); -return err; - } - } +if (err == -ENODATA && +ipv6_addr_is_all_snoopers (&ipv6_hdr (skb)->daddr)) +br_ip6_multicast_mrd_rcv (br, port, skb);return 0 ; }else if (err <0 ) {
net/ipv6/mcast_snoop.c +7 -5
@@ -109,7 +109,7 @@ static int ipv6_mc_check_mld_msg(struct sk_buff *skb)struct mld_msg *mld;if (!ipv6_mc_may_pull (skb, len)) -return -EINVAL ; +return -ENODATA ; mld = (struct mld_msg *)skb_transport_header (skb);
@@ -122,7 +122,7 @@ static int ipv6_mc_check_mld_msg(struct sk_buff *skb)case ICMPV6_MGM_QUERY :return ipv6_mc_check_mld_query (skb);default : -return -ENOMSG ; +return -ENODATA ; } }
@@ -131,7 +131,7 @@ static inline __sum16 ipv6_mc_validate_checksum(struct sk_buff *skb)return skb_checksum_validate (skb,IPPROTO_ICMPV6 , ip6_compute_pseudo); } -int ipv6_mc_check_icmpv6 (struct sk_buff *skb) +static int ipv6_mc_check_icmpv6 (struct sk_buff *skb) {unsigned int len =skb_transport_offset (skb) +sizeof (struct icmp6hdr );unsigned int transport_len =ipv6_transport_len (skb);
@@ -150,7 +150,6 @@ int ipv6_mc_check_icmpv6(struct sk_buff *skb)return 0 ; } -EXPORT_SYMBOL (ipv6_mc_check_icmpv6);/** * ipv6_mc_check_mld - checks whether this is a sane MLD packet
@@ -161,7 +160,10 @@ EXPORT_SYMBOL(ipv6_mc_check_icmpv6);* * -EINVAL: A broken packet was detected, i.e. it violates some internet * standard -* -ENOMSG: IP header validation succeeded but it is not an MLD packet. +* -ENOMSG: IP header validation succeeded but it is not an ICMPv6 packet +* with a hop-by-hop option. +* -ENODATA: IP+ICMPv6 header with hop-by-hop option validation succeeded +* but it is not an MLD packet. * -ENOMEM: A memory allocation failure happened. * * Caller needs to set the skb network header and free any returned skb if it
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 235/244 net:nfc:digital: Fix a double free in digital_tg_recv_dep_req
In reply to Greg Kroah-HartmanFrom: Lv Yunlong <[email protected]>
[ Upstream commit 75258586793efc521e5dd52a5bf6c7a4cf7002be ]
In digital_tg_recv_dep_req, it calls nfc_tm_data_received(..,resp). If nfc_tm_data_received() failed, the callee will free the resp via kfree_skb() and return error. But in the exit branch, the resp will be freed again.
My patch sets resp to NULL if nfc_tm_data_received() failed, to avoid the double free.
--- net/nfc/digital_dep.c | 2 ++ 1 file changed, 2 insertions(+)
net/nfc/digital_dep.c +2 -0
@@ -1276,6 +1276,8 @@ static void digital_tg_recv_dep_req(struct nfc_digital_dev *ddev, void *arg, } rc =nfc_tm_data_received (ddev->nfc_dev, resp); +if (rc) + resp =NULL ; exit:kfree_skb (ddev->chaining_skb);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 236/244 kfifo: fix ternary sign extension bugs
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit 926ee00ea24320052b46745ef4b00d91c05bd03d ]
The intent with this code was to return negative error codes but instead it returns positives.
The problem is how type promotion works with ternary operations. These functions return long, "ret" is an int and "copied" is a u32. The negative error code is first cast to u32 so it becomes a high positive and then cast to long where it's still a positive.
We could fix this by declaring "ret" as a ssize_t but let's just get rid of the ternaries instead.
--- samples/kfifo/bytestream-example.c | 8 ++++++-- samples/kfifo/inttype-example.c | 8 ++++++-- samples/kfifo/record-example.c | 8 ++++++-- 3 files changed, 18 insertions(+), 6 deletions(-)
samples/kfifo/bytestream-example.c +6 -2
@@ -122,8 +122,10 @@ static ssize_t fifo_write(struct file *file, const char __user *buf, ret =kfifo_from_user (&test, buf, count, &copied);mutex_unlock (&write_lock); +if (ret) +return ret; -return ret ? ret : copied; +return copied; } static ssize_t fifo_read(struct file *file, char __user *buf,
@@ -138,8 +140,10 @@ static ssize_t fifo_read(struct file *file, char __user *buf, ret =kfifo_to_user (&test, buf, count, &copied);mutex_unlock (&read_lock); +if (ret) +return ret; -return ret ? ret : copied; +return copied; }static const struct file_operations fifo_fops = {
samples/kfifo/inttype-example.c +6 -2
@@ -115,8 +115,10 @@ static ssize_t fifo_write(struct file *file, const char __user *buf, ret =kfifo_from_user (&test, buf, count, &copied);mutex_unlock (&write_lock); +if (ret) +return ret; -return ret ? ret : copied; +return copied; } static ssize_t fifo_read(struct file *file, char __user *buf,
@@ -131,8 +133,10 @@ static ssize_t fifo_read(struct file *file, char __user *buf, ret =kfifo_to_user (&test, buf, count, &copied);mutex_unlock (&read_lock); +if (ret) +return ret; -return ret ? ret : copied; +return copied; }static const struct file_operations fifo_fops = {
samples/kfifo/record-example.c +6 -2
@@ -129,8 +129,10 @@ static ssize_t fifo_write(struct file *file, const char __user *buf, ret =kfifo_from_user (&test, buf, count, &copied);mutex_unlock (&write_lock); +if (ret) +return ret; -return ret ? ret : copied; +return copied; } static ssize_t fifo_read(struct file *file, char __user *buf,
@@ -145,8 +147,10 @@ static ssize_t fifo_read(struct file *file, char __user *buf, ret =kfifo_to_user (&test, buf, count, &copied);mutex_unlock (&read_lock); +if (ret) +return ret; -return ret ? ret : copied; +return copied; }static const struct file_operations fifo_fops = {
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 237/244 mm/sparse: add the missing sparse_buffer_fini() in error branch
In reply to Greg Kroah-HartmanFrom: Wang Wensheng <[email protected]>
[ Upstream commit 2284f47fe9fe2ed2ef619e5474e155cfeeebd569 ]
sparse_buffer_init() and sparse_buffer_fini() should appear in pair, or a WARN issue would be through the next time sparse_buffer_init() runs.
Add the missing sparse_buffer_fini() in error branch.
--- mm/sparse.c | 1 + 1 file changed, 1 insertion(+)
mm/sparse.c +1 -0
@@ -551,6 +551,7 @@ static void __init sparse_init_nid(int nid, unsigned long pnum_begin,pr_err ("%s: node[%d] memory map backing failed. Some memory will not be available." , __func__, nid); pnum_begin = pnum; +sparse_buffer_fini (); goto failed; }check_usemap_section_nr (nid, usage);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 238/244 mm/memory-failure: unnecessary amount of unmapping
In reply to Greg Kroah-HartmanFrom: Jane Chu <[email protected]>
[ Upstream commit 4d75136be8bf3ae01b0bc3e725b2cdc921e103bd ]
It appears that unmap_mapping_range() actually takes a 'size' as its third argument rather than a location, the current calling fashion causes unnecessary amount of unmapping to occur.
--- mm/memory-failure.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/memory-failure.c +1 -1
@@ -1215,7 +1215,7 @@ static int memory_failure_dev_pagemap(unsigned long pfn, int flags,* communicated in siginfo, see kill_proc() */ start = (page->index <<PAGE_SHIFT ) & ~(size -1 ); -unmap_mapping_range (page->mapping, start, start + size,0 ); +unmap_mapping_range (page->mapping, start, size,0 ); }kill_procs (&tokill, flags &MF_MUST_KILL , !unmap_success, pfn, flags); rc =0 ;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 239/244 net: Only allow init netns to set default tcp cong to a restricted algo
In reply to Greg Kroah-HartmanFrom: Jonathon Reinhart <[email protected]>
commit 8d432592f30fcc34ef5a10aac4887b4897884493 upstream.
tcp_set_default_congestion_control() is netns-safe in that it writes to &net->ipv4.tcp_congestion_control, but it also sets ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced. This has the unintended side-effect of changing the global net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control readonly in non-init netns")
Resolve this netns "leak" by only allowing the init netns to set the default algorithm to one that is restricted. This restriction could be removed if tcp_allowed_congestion_control were namespace-ified in the future.
This bug was uncovered with
https://github.com/JonathonReinhart/linux-netns-sysctl-verify
--- net/ipv4/tcp_cong.c | 4 ++++ 1 file changed, 4 insertions(+)
net/ipv4/tcp_cong.c +4 -0
@@ -229,6 +229,10 @@ int tcp_set_default_congestion_control(s ret = -ENOENT ; }else if (!try_module_get (ca->owner)) { ret = -EBUSY ; + }else if (!net_eq (net, &init_net) && + !(ca->flags &TCP_CONG_NON_RESTRICTED )) { +/* Only init netns can set default to a restricted algorithm */ + ret = -EPERM ; }else { prev =xchg (&net->ipv4.tcp_congestion_control, ca);if (prev)
Greg Kroah-Hartman
maintainerPATCH 240/244 smp: Fix smp_call_function_single_async prototype
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
commit 1139aeb1c521eb4a050920ce6c64c36c4f2a3ab7 upstream.
As of commit 966a967116e6 ("smp: Avoid using two cache lines for struct call_single_data"), the smp code prefers 32-byte aligned call_single_data objects for performance reasons, but the block layer includes an instance of this structure in the main 'struct request' that is more senstive to size than to performance here, see 4ccafe032005 ("block: unalign call_single_data in struct request").
The result is a violation of the calling conventions that clang correctly points out:
block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to 32-byte aligned parameter 2 of 'smp_call_function_single_async' may result in an unaligned pointer access [-Walign-mismatch]
smp_call_function_single_async(cpu, &rq->csd);
It does seem that the usage of the call_single_data without cache line alignment should still be allowed by the smp code, so just change the function prototype so it accepts both, but leave the default alignment unchanged for the other users. This seems better to me than adding a local hack to shut up an otherwise correct warning in the caller.
--- include/linux/smp.h | 2 +- kernel/smp.c | 10 +++++----- kernel/up.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)
include/linux/smp.h +1 -1
@@ -57,7 +57,7 @@ void on_each_cpu_cond_mask(bool (*cond_f smp_call_func_t func, void *info, bool wait, gfp_t gfp_flags, const struct cpumask *mask); -int smp_call_function_single_async (int cpu,call_single_data_t *csd); +int smp_call_function_single_async (int cpu,struct __call_single_data *csd);#ifdef CONFIG_SMP
kernel/smp.c +5 -5
@@ -104,12 +104,12 @@ void __init call_function_init(void)* previous function call. For multi-cpu calls its even more interesting * as we'll have to ensure no other cpu is observing our csd. */ -static __always_inline void csd_lock_wait(call_single_data_t *csd) +static __always_inline void csd_lock_wait(struct __call_single_data *csd) {smp_cond_load_acquire (&csd->flags, !(VAL &CSD_FLAG_LOCK )); } -static __always_inline void csd_lock(call_single_data_t *csd) +static __always_inline void csd_lock(struct __call_single_data *csd) {csd_lock_wait (csd); csd->flags |=CSD_FLAG_LOCK ;
@@ -122,7 +122,7 @@ static __always_inline void csd_lock(calsmp_wmb (); } -static __always_inline void csd_unlock(call_single_data_t *csd) +static __always_inline void csd_unlock(struct __call_single_data *csd) {WARN_ON (!(csd->flags &CSD_FLAG_LOCK ));
@@ -139,7 +139,7 @@ static DEFINE_PER_CPU_SHARED_ALIGNED(cal* for execution on the given CPU. data must already have * ->func, ->info, and ->flags set. */ -static int generic_exec_single (int cpu,call_single_data_t *csd, +static int generic_exec_single (int cpu,struct __call_single_data *csd,smp_call_func_t func,void *info) {if (cpu ==smp_processor_id ()) {
@@ -332,7 +332,7 @@ EXPORT_SYMBOL(smp_call_function_single);* NOTE: Be careful, there is unfortunately no current debugging facility to * validate the correctness of this serialization. */ -int smp_call_function_single_async (int cpu,call_single_data_t *csd) +int smp_call_function_single_async (int cpu,struct __call_single_data *csd) {int err =0 ;
kernel/up.c +1 -1
@@ -24,7 +24,7 @@ int smp_call_function_single(int cpu, vo }EXPORT_SYMBOL (smp_call_function_single); -int smp_call_function_single_async (int cpu,call_single_data_t *csd) +int smp_call_function_single_async (int cpu,struct __call_single_data *csd) {unsigned long flags;
Greg Kroah-Hartman
maintainerPATCH 241/244 Revert "net/sctp: fix race condition in sctp_destroy_sock"
In reply to Greg Kroah-HartmanFrom: Xin Long <[email protected]>
commit 01bfe5e8e428b475982a98a46cca5755726f3f7f upstream.
This reverts commit b166a20b07382b8bc1dcee2a448715c9c2c81b5b.
This one has to be reverted as it introduced a dead lock, as syzbot reported:
CPU0 CPU1
---- ----
lock(&net->sctp.addr_wq_lock);
lock(slock-AF_INET6);
lock(&net->sctp.addr_wq_lock); lock(slock-AF_INET6);
CPU0 is the thread of sctp_addr_wq_timeout_handler(), and CPU1 is that of sctp_close().
The original issue this commit fixed will be fixed in the next patch.
--- net/sctp/socket.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
net/sctp/socket.c +8 -5
@@ -1539,9 +1539,11 @@ static void sctp_close(struct sock *sk,/* Supposedly, no process has access to the socket, but * the net layers still may. +* Also, sctp_destroy_sock() needs to be called with addr_wq_lock +* held and that should be grabbed before socket lock. */ -local_bh_disable (); -bh_lock_sock (sk); +spin_lock_bh (&net->sctp.addr_wq_lock); +bh_lock_sock_nested (sk);/* Hold the sock, since sk_common_release() will put sock_put() * and we have just a little more cleanup.
@@ -1550,7 +1552,7 @@ static void sctp_close(struct sock *sk,sk_common_release (sk);bh_unlock_sock (sk); -local_bh_enable (); +spin_unlock_bh (&net->sctp.addr_wq_lock);sock_put (sk);
@@ -5113,6 +5115,9 @@ static int sctp_init_sock(struct sock *ssk_sockets_allocated_inc (sk);sock_prot_inuse_add (net, sk->sk_prot,1 ); +/* Nothing can fail after this block, otherwise +* sctp_destroy_sock() will be called without addr_wq_lock held +*/ if (net->sctp.default_auto_asconf) {spin_lock (&sock_net (sk)->sctp.addr_wq_lock); list_add_tail(&sp->auto_asconf_list,
@@ -5147,9 +5152,7 @@ static void sctp_destroy_sock(struct socif (sp->do_auto_asconf) { sp->do_auto_asconf =0 ; -spin_lock_bh (&sock_net (sk)->sctp.addr_wq_lock);list_del (&sp->auto_asconf_list); -spin_unlock_bh (&sock_net (sk)->sctp.addr_wq_lock); }sctp_endpoint_free (sp->ep);local_bh_disable ();
Greg Kroah-Hartman
maintainerPATCH 242/244 sctp: delay auto_asconf init until binding the first addr
In reply to Greg Kroah-HartmanFrom: Xin Long <[email protected]>
commit 34e5b01186858b36c4d7c87e1a025071e8e2401f upstream.
As Or Cohen described:
If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock held and sp->do_auto_asconf is true, then an element is removed from the auto_asconf_splist without any proper locking.
This can happen in the following functions:
1. In sctp_accept, if sctp_sock_migrate fails.
2. In inet_create or inet6_create, if there is a bpf program attached to BPF_CGROUP_INET_SOCK_CREATE which denies creation of the sctp socket.
This patch is to fix it by moving the auto_asconf init out of sctp_init_sock(), by which inet_create()/inet6_create() won't need to operate it in sctp_destroy_sock() when calling sk_common_release().
It also makes more sense to do auto_asconf init while binding the first addr, as auto_asconf actually requires an ANY addr bind, see it in sctp_addr_wq_timeout_handler().
This addresses CVE-2021-23133.
--- net/sctp/socket.c | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-)
net/sctp/socket.c +17 -14
@@ -357,6 +357,18 @@ static struct sctp_af *sctp_sockaddr_af(return af; } +static void sctp_auto_asconf_init (struct sctp_sock *sp) +{ +struct net *net =sock_net (&sp->inet.sk); + +if (net->sctp.default_auto_asconf) { +spin_lock (&net->sctp.addr_wq_lock); +list_add_tail (&sp->auto_asconf_list, &net->sctp.auto_asconf_splist); +spin_unlock (&net->sctp.addr_wq_lock); + sp->do_auto_asconf =1 ; + } +} +/* Bind a local address either to an endpoint or to an association. */ static int sctp_do_bind (struct sock *sk,union sctp_addr *addr,int len) {
@@ -418,8 +430,10 @@ static int sctp_do_bind(struct sock *sk,return -EADDRINUSE ;/* Refresh ephemeral port. */ -if (!bp->port) +if (!bp->port) { bp->port =inet_sk (sk)->inet_num; +sctp_auto_asconf_init (sp); + }/* Add the address to the bind address list. * Use GFP_ATOMIC since BHs will be disabled.
@@ -5115,19 +5129,6 @@ static int sctp_init_sock(struct sock *ssk_sockets_allocated_inc (sk);sock_prot_inuse_add (net, sk->sk_prot,1 ); -/* Nothing can fail after this block, otherwise -* sctp_destroy_sock() will be called without addr_wq_lock held -*/ -if (net->sctp.default_auto_asconf) { -spin_lock (&sock_net (sk)->sctp.addr_wq_lock); -list_add_tail (&sp->auto_asconf_list, - &net->sctp.auto_asconf_splist); - sp->do_auto_asconf =1 ; -spin_unlock (&sock_net (sk)->sctp.addr_wq_lock); - }else { - sp->do_auto_asconf =0 ; - } -local_bh_enable ();return 0 ;
@@ -9402,6 +9403,8 @@ static int sctp_sock_migrate(struct sockreturn err; } +sctp_auto_asconf_init (newsp); +/* Move any messages in the old socket's receive queue that are for the * peeled off association to the new socket's receive queue. */
Greg Kroah-Hartman
maintainerPATCH 243/244 Revert "of/fdt: Make sure no-map does not remove already reserved regions"
In reply to Greg Kroah-HartmanFrom: Quentin Perret <[email protected]>
This reverts commit 3cbd3038c9155038020560729cde50588311105d. It is not really a fix, and the backport misses dependencies, which breaks existing platforms.
--- drivers/of/fdt.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
drivers/of/fdt.c +1 -9
@@ -1153,16 +1153,8 @@ int __init __weak early_init_dt_mark_hotint __init __weak early_init_dt_reserve_memory_arch (phys_addr_t base,phys_addr_t size,bool nomap) { -if (nomap) { -/* -* If the memory is already reserved (by another region), we -* should not allow it to be marked nomap. -*/ -if (memblock_is_region_reserved (base, size)) -return -EBUSY ; - +if (nomap)return memblock_mark_nomap (base, size); - }return memblock_reserve (base, size); }
Greg Kroah-Hartman
maintainerPATCH 244/244 Revert "fdt: Properly handle "no-map" field in the memory region"
In reply to Greg Kroah-HartmanFrom: Quentin Perret <[email protected]>
This reverts commit fb326c6ce0dcbb6273202c6e012759754ec8538d. It is not really a fix, and the backport misses dependencies, which breaks existing platforms.
--- drivers/of/fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/of/fdt.c +1 -1
@@ -1154,7 +1154,7 @@ int __init __weak early_init_dt_reserve_ phys_addr_t size, bool nomap) { if (nomap) - return memblock_mark_nomap(base, size); + return memblock_remove(base, size);return memblock_reserve (base, size); }
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Build regression detected.
Quoted 2 lines
Alexandru Elisei <[email protected]>
KVM: arm64: Initialize VCPUmdcr_el2before loading it
stable rc 5.4 arm axm55xx_defconfig builds failed due to these warnings / errors.
- arm (axm55xx_defconfig) with gcc-8,9 and 10 failed
arch/arm/kvm/../../../virt/kvm/arm/arm.c: In function 'kvm_vcpu_first_run_init':arch/arm/kvm/../../../virt/kvm/arm/arm.c:582:2: error: implicit declaration of function 'kvm_arm_vcpu_init_debug'; did you mean 'kvm_arm_init_debug'? [-Werror=implicit-function-declaration]
kvm_arm_vcpu_init_debug(vcpu);
^~~~~~~~~~~~~~~~~~~~~~~
kvm_arm_init_debug
cc1: some warnings being treated as errors
steps to reproduce:
--------------------
#!/bin/sh
# TuxMake is a command line tool and Python library that provides
# portable and repeatable Linux kernel builds across a variety of # architectures, toolchains, kernel configurations, and make targets. # # TuxMake supports the concept of runtimes. # See https://docs.tuxmake.org/runtimes/, for that to work it requires # that you install podman or docker on your system. # # To install tuxmake on your system globally: # sudo pip3 install -U tuxmake # # See https://docs.tuxmake.org/ for complete documentation.
tuxmake --runtime podman --target-arch arm --toolchain gcc-8 --kconfig axm55xx_defconfig
ref:
https://builds.tuxbuild.com/1sRT0HOyHnZ8N5ktJmaEcMIQZL0/
--
Linaro LKFT
https://lkft.linaro.org
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Naresh,
Thank you for the report!
Quoted 27 lines · Naresh Kamboju
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Build regression detected.
Quoted 2 lines
Alexandru Elisei <[email protected]>
KVM: arm64: Initialize VCPUmdcr_el2before loading itstable rc 5.4 arm
axm55xx_defconfigbuilds failed due to these warnings / errors.
- arm (axm55xx_defconfig) with gcc-8,9 and 10 failed
Quoted 8 lines
arch/arm/kvm/../../../virt/kvm/arm/arm.c: In function 'kvm_vcpu_first_run_init':arch/arm/kvm/../../../virt/kvm/arm/arm.c:582:2: error: implicit declaration of function 'kvm_arm_vcpu_init_debug'; did you mean 'kvm_arm_init_debug'? [-Werror=implicit-function-declaration]
kvm_arm_vcpu_init_debug(vcpu);
^~~~~~~~~~~~~~~~~~~~~~~
kvm_arm_init_debug
cc1: some warnings being treated as errors
This is my fault, in Linux v5.4 KVM for arm is still around, and there's no prototype for the function when compiling for arm. I suspect that's also the case for v4.19.
I made this change to get it to build:
$ git diff
arch/arm/include/asm/kvm_host.h +0 -0
@@ -335,6 +335,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu,
int cpu) {}
static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
static inline void kvm_arm_init_debug(void) {}
+static inline void kvm_arm_vcpu_init_debug(struct kvm_vcpu *vcpu) {} static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {} static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {} static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
which matches the stub for kvm_arm_init_debug(). I can spin a patch out of it and send it for 5.4 and 4.19. Marc, what do you think?
Thanks,
Alex
Quoted 23 lines
steps to reproduce:
--------------------
#!/bin/sh# TuxMake is a command line tool and Python library that provides
# portable and repeatable Linux kernel builds across a variety of # architectures, toolchains, kernel configurations, and make targets. # # TuxMake supports the concept of runtimes. # See https://docs.tuxmake.org/runtimes/, for that to work it requires # that you install podman or docker on your system. # # To install tuxmake on your system globally: # sudo pip3 install -U tuxmake # # See https://docs.tuxmake.org/ for complete documentation.tuxmake --runtime podman --target-arch arm --toolchain gcc-8 --kconfig
axm55xx_defconfig
Quoted 7 lines
ref:
https://builds.tuxbuild.com/1sRT0HOyHnZ8N5ktJmaEcMIQZL0/--
Linaro LKFT
https://lkft.linaro.org
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerQuoted 63 lines · Alexandru Elisei
Hi Naresh,
Thank you for the report!
Quoted 27 lines · Naresh Kamboju
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Build regression detected.
Quoted 2 lines
Alexandru Elisei <[email protected]>
KVM: arm64: Initialize VCPUmdcr_el2before loading itstable rc 5.4 arm
axm55xx_defconfigbuilds failed due to these warnings / errors.
- arm (axm55xx_defconfig) with gcc-8,9 and 10 failedQuoted 8 lines
arch/arm/kvm/../../../virt/kvm/arm/arm.c: In function 'kvm_vcpu_first_run_init':arch/arm/kvm/../../../virt/kvm/arm/arm.c:582:2: error: implicit declaration of function 'kvm_arm_vcpu_init_debug'; did you mean 'kvm_arm_init_debug'? [-Werror=implicit-function-declaration]
kvm_arm_vcpu_init_debug(vcpu);
^~~~~~~~~~~~~~~~~~~~~~~
kvm_arm_init_debug
cc1: some warnings being treated as errorsThis is my fault, in Linux v5.4 KVM for arm is still around, and there's no prototype for the function when compiling for arm. I suspect that's also the case for v4.19.
I made this change to get it to build:
$ git diffarch/arm/include/asm/kvm_host.h +0
-0@@ -335,6 +335,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {} static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
static inline voidkvm_arm_init_debug(void){}
+static inline voidkvm_arm_vcpu_init_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_setup_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_clear_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu){}
Quoted 2 lines
which matches the stub for
kvm_arm_init_debug(). I can spin a patch out of it and send it for 5.4 and 4.19. Marc, what do you think?
Ideally, we'd drop the patch in its current form from 5.4 and 4.19, and send an updated patch with this hunk to fix the 32bit build.
Thanks,
M.
Signature · 5 lines
Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Greg Kroah-Hartman
maintainerQuoted 65 lines · Marc Zyngier
Quoted 63 lines · Alexandru Elisei
Hi Naresh,
Thank you for the report!
Quoted 27 lines · Naresh Kamboju
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Build regression detected.
Quoted 2 lines
Alexandru Elisei <[email protected]>
KVM: arm64: Initialize VCPUmdcr_el2before loading itstable rc 5.4 arm
axm55xx_defconfigbuilds failed due to these warnings / errors.
- arm (axm55xx_defconfig) with gcc-8,9 and 10 failedQuoted 8 lines
arch/arm/kvm/../../../virt/kvm/arm/arm.c: In function 'kvm_vcpu_first_run_init':arch/arm/kvm/../../../virt/kvm/arm/arm.c:582:2: error: implicit declaration of function 'kvm_arm_vcpu_init_debug'; did you mean 'kvm_arm_init_debug'? [-Werror=implicit-function-declaration]
kvm_arm_vcpu_init_debug(vcpu);
^~~~~~~~~~~~~~~~~~~~~~~
kvm_arm_init_debug
cc1: some warnings being treated as errorsThis is my fault, in Linux v5.4 KVM for arm is still around, and there's no prototype for the function when compiling for arm. I suspect that's also the case for v4.19.
I made this change to get it to build:
$ git diffarch/arm/include/asm/kvm_host.h +0
-0@@ -335,6 +335,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {} static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
static inline voidkvm_arm_init_debug(void){}
+static inline voidkvm_arm_vcpu_init_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_setup_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_clear_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu){}
Quoted 6 lines
Quoted 2 lines
which matches the stub for
kvm_arm_init_debug(). I can spin a patch out of it and send it for 5.4 and 4.19. Marc, what do you think?Ideally, we'd drop the patch in its current form from 5.4 and 4.19, and send an updated patch with this hunk to fix the 32bit build.
That would be great. Do you want to do it for this set of releases (i.e. today/tomorrow) or have me just drop this now and someone will send me an updated version later when they get a chance?
thanks,
greg k-h
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Sasha Levin
maintainerQuoted 19 lines · Marc Zyngier
Quoted 17 lines · Alexandru Elisei
I made this change to get it to build:
$ git diffarch/arm/include/asm/kvm_host.h +0
-0@@ -335,6 +335,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {} static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
static inline voidkvm_arm_init_debug(void){}
+static inline voidkvm_arm_vcpu_init_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_setup_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_clear_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu){}
Quoted 5 lines
Quoted 2 lines
which matches the stub for
kvm_arm_init_debug(). I can spin a patch out of it and send it for 5.4 and 4.19. Marc, what do you think?Ideally, we'd drop the patch in its current form from 5.4 and 4.19, and send an updated patch with this hunk to fix the 32bit build.
Yes please. I've dropped it from 5.4 and 4.19 and we can queue up a fixed backport for the next round of releases.
Signature · 6 lines
Thanks, Sasha _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Quoted 41 lines · Alexandru Elisei
Hi Naresh,
Thank you for the report!
Quoted 27 lines · Naresh Kamboju
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Build regression detected.
Quoted 2 lines
Alexandru Elisei <[email protected]>
KVM: arm64: Initialize VCPUmdcr_el2before loading itstable rc 5.4 arm
axm55xx_defconfigbuilds failed due to these warnings / errors.
- arm (axm55xx_defconfig) with gcc-8,9 and 10 failedQuoted 8 lines
arch/arm/kvm/../../../virt/kvm/arm/arm.c: In function 'kvm_vcpu_first_run_init':arch/arm/kvm/../../../virt/kvm/arm/arm.c:582:2: error: implicit declaration of function 'kvm_arm_vcpu_init_debug'; did you mean 'kvm_arm_init_debug'? [-Werror=implicit-function-declaration]
kvm_arm_vcpu_init_debug(vcpu);
^~~~~~~~~~~~~~~~~~~~~~~
kvm_arm_init_debug
cc1: some warnings being treated as errors
Quoted 4 lines
This is my fault, in Linux v5.4 KVM for arm is still around, and there's no prototype for the function when compiling for arm. I suspect that's also the case for v4.19.
Correct.
Guenter
Quoted 17 lines
I made this change to get it to build:
$ git diffarch/arm/include/asm/kvm_host.h +0
-0@@ -335,6 +335,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {} static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
static inline voidkvm_arm_init_debug(void){}
+static inline voidkvm_arm_vcpu_init_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_setup_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_clear_debug(struct kvm_vcpu *vcpu){} static inline voidkvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu){}
Quoted 37 lines
which matches the stub for
kvm_arm_init_debug(). I can spin a patch out of it and send it for 5.4 and 4.19. Marc, what do you think?Thanks,
Alex
Quoted 30 lines
steps to reproduce:
--------------------
#!/bin/sh# TuxMake is a command line tool and Python library that provides
# portable and repeatable Linux kernel builds across a variety of # architectures, toolchains, kernel configurations, and make targets. # # TuxMake supports the concept of runtimes. # See https://docs.tuxmake.org/runtimes/, for that to work it requires # that you install podman or docker on your system. # # To install tuxmake on your system globally: # sudo pip3 install -U tuxmake # # See https://docs.tuxmake.org/ for complete documentation.tuxmake --runtime podman --target-arch arm --toolchain gcc-8 --kconfig
axm55xx_defconfigref:
https://builds.tuxbuild.com/1sRT0HOyHnZ8N5ktJmaEcMIQZL0/--
Linaro LKFT
https://lkft.linaro.org
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Alex,
Quoted 63 lines · Alexandru Elisei
Hi Naresh,
Thank you for the report!
Quoted 27 lines · Naresh Kamboju
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Build regression detected.
Quoted 2 lines
Alexandru Elisei <[email protected]>
KVM: arm64: Initialize VCPUmdcr_el2before loading itstable rc 5.4 arm
axm55xx_defconfigbuilds failed due to these warnings / errors.
- arm (axm55xx_defconfig) with gcc-8,9 and 10 failedQuoted 8 lines
arch/arm/kvm/../../../virt/kvm/arm/arm.c: In function 'kvm_vcpu_first_run_init':arch/arm/kvm/../../../virt/kvm/arm/arm.c:582:2: error: implicit declaration of function 'kvm_arm_vcpu_init_debug'; did you mean 'kvm_arm_init_debug'? [-Werror=implicit-function-declaration]
kvm_arm_vcpu_init_debug(vcpu);
^~~~~~~~~~~~~~~~~~~~~~~
kvm_arm_init_debug
cc1: some warnings being treated as errorsThis is my fault, in Linux v5.4 KVM for arm is still around, and there's no prototype for the function when compiling for arm. I suspect that's also the case for v4.19.
I made this change to get it to build:
$ git diffarch/arm/include/asm/kvm_host.h +1
-0@@ -335,6 +335,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}static inline void kvm_arch_vcpu_block_finish (struct kvm_vcpu *vcpu) {}static inline void kvm_arm_init_debug (void ) {} +static inline void kvm_arm_vcpu_init_debug (struct kvm_vcpu *vcpu) {}static inline void kvm_arm_setup_debug (struct kvm_vcpu *vcpu) {}static inline void kvm_arm_clear_debug (struct kvm_vcpu *vcpu) {}static inline void
kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu){}
Quoted 2 lines
which matches the stub for
kvm_arm_init_debug(). I can spin a patch out of it and send it for 5.4 and 4.19. Marc, what do you think?
FYI,
This proposed fix patch applied and built PASS on the arm. (you may apply this patch for the next round of stable rc review)
- Naresh
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.4:
12 builds: 12 pass, 0 fail
26 boots: 26 pass, 0 fail
59 tests: 59 pass, 0 failLinux version: 5.4.119-rc1-g12be7a21d622
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Tested on arm64 and x86 for 5.4.119-rc1,
Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.4.y
Version: 5.4.119-rc1
Commit: cca16b363311e59d7dc42bf04f680c207d647118
Compiler: gcc version 7.3.0 (GCC)
arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8476
passed: 8476
failed: 0
timeout: 0
--------------------------------------------------------------------
x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8476
passed: 8476
failed: 0
timeout: 0
--------------------------------------------------------------------
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
Build test:
mips (gcc version 11.1.1 20210430): 65 configs -> 1 new failure
malta_qemu_32r6_defconfig fails due to:
[PATCH 5.4 035/244] MIPS: Reinstate platform `__div64_32 handler
arm (gcc version 11.1.1 20210430): 107 configs -> no new failure x86_64 (gcc version 10.2.1 20210110): 2 configs -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression.
--
Regards
Sudip
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Apart from the mips clang build failures no other new test failures noticed.
## Build
* kernel: 5.4.119-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.4.y
* git commit: 12be7a21d6221f3522c583c1d0407ac22578bd85
* git describe: v5.4.117-430-g12be7a21d622
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.117-430-g12be7a21d622
## Regressions (compared to v5.4.117)
* arm, build
- clang-10-axm55xx_defconfig
- clang-11-axm55xx_defconfig
- clang-12-axm55xx_defconfig
- gcc-10-axm55xx_defconfig
- gcc-8-axm55xx_defconfig
- gcc-9-axm55xx_defconfig
* mips, build
- clang-10-allnoconfig
- clang-10-defconfig
- clang-10-tinyconfig
- clang-11-allnoconfig
- clang-11-defconfig
- clang-11-tinyconfig
- clang-12-allnoconfig
- clang-12-defconfig
- clang-12-tinyconfig
## No fixes (compared to v5.4.117)
## Test result summary
total: 69342, pass: 57571, fail: 1395, skip: 10128, xfail: 248,
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 192 total, 186 passed, 6 failed
* arm64: 26 total, 26 passed, 0 failed
* i386: 14 total, 14 passed, 0 failed
* mips: 45 total, 36 passed, 9 failed
* parisc: 9 total, 9 passed, 0 failed
* powerpc: 27 total, 27 passed, 0 failed
* riscv: 21 total, 21 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 18 total, 18 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x86_64: 26 total, 26 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kvm
* kselftest-lib
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* 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-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.119 release. There are 244 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 Fri, 14 May 2021 14:47:09 +0000. Anything received after that time might be too late.
Build results:
total: 157 pass: 156 fail: 1 Failed builds: arm:axm55xx_defconfig Qemu test results: total: 428 pass: 427 fail: 1
Failed tests:
mipsel:mips32r6-generic:malta_32r6_defconfig:nocd:smp:net,pcnet:ide:rootfs
Failures are as already reported.
Guenter