- 31 Mar, 2022 21 commits
-
-
Paolo Abeni authored
Jakub Kicinski says: ==================== docs: update and move the netdev-FAQ A section of documentation for tree-specific process quirks had been created a while back. There's only one tree in it, so far, the tip tree, but the contents seem to answer similar questions as we answer in the netdev-FAQ. Move the netdev-FAQ. Take this opportunity to touch up and update a few sections. v3: remove some confrontational? language from patch 7 v2: remove non-git in patch 3 add patch 5 ==================== Link: https://lore.kernel.org/r/20220330042505.2902770-1-kuba@kernel.orgSigned-off-by:Paolo Abeni <pabeni@redhat.com>
-
Jakub Kicinski authored
The documentation for the tip tree is really in quite a similar spirit to the netdev-FAQ. Move the netdev-FAQ to the process docs as well. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
Convert the "should I use new or old comment formatting" to cover all formatting. This makes the question itself shorter. Signed-off-by:
-
Jakub Kicinski authored
Add the most important case to the question about "where are we in the cycle" - the case of net-next being closed. Signed-off-by:
-
Jakub Kicinski authored
I think double back ticks are more correct. Add where they are missing. Signed-off-by:
-
Jakub Kicinski authored
These days we often ask for selftests so let's update our testing requirements. Signed-off-by:
-
Jakub Kicinski authored
We have to tell people to stop reposting to often lately, or not to repost while the discussion is ongoing. Document this. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Jakub Kicinski authored
Make the question shorter and adjust the start of the answer accordingly. Signed-off-by:
-
Jakub Kicinski authored
The semantics of "Under review" have shifted. Reword the question about it a bit and focus it on the response time. Signed-off-by:
-
Jakub Kicinski authored
Cut down the length of the question so it renders better in docs. Mention that Message-ID can be used to search patchwork. Signed-off-by:
-
Jakub Kicinski authored
Document that RFCs are allowed during the merge window. Signed-off-by:
-
Jakub Kicinski authored
Use the sphinx Warning box to make the net-next being closed stand out more. Signed-off-by:
-
Jakub Kicinski authored
We want people to mark their patches with net and net-next in the subject. Many miss doing that. Move the FAQ section which points that out up, and place it after the section which enumerates the trees, that seems like a pretty logical place for it. Since the two sections are together we can remove a little bit (not too much) of the repetition. v2: also remove the text for non-git setups, we want people to use git. Signed-off-by:
-
Jakub Kicinski authored
that -> those Signed-off-by:
-
Jakub Kicinski authored
Most people use (or should use) lore at this point. Replace the pointers to older archiving systems. Signed-off-by:
-
Randy Dunlap authored
Fix build errors when BRIDGE=m and SPARX5_SWITCH=y: riscv64-linux-ld: drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.o: in function `.L305': sparx5_switchdev.c:(.text+0xdb0): undefined reference to `br_vlan_enabled' riscv64-linux-ld: drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.o: in function `.L283': sparx5_switchdev.c:(.text+0xee0): undefined reference to `br_vlan_enabled' Fixes: 3cfa11ba ("net: sparx5: add the basic sparx5 driver") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Cc: Horatiu Vultur <horatiu.vultur@microchip.com> Cc: Lars Povlsen <lars.povlsen@microchip.com> Cc: Steen Hegelund <Steen.Hegelund@microchip.com> Cc: UNGLinuxDriver@microchip.com Cc: Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/20220330012025.29560-1-rdunlap@infradead.orgSigned-off-by:
-
Jakub Kicinski authored
Jason A. Donenfeld says: ==================== wireguard patches for 5.18-rc1 Here's a small set of fixes for the next net push: 1) Pipacs reported a CFI violation in a cleanup routine, which he triggered using grsec's RAP. I haven't seen reports of this yet from the Android/CFI world yet, but it's only a matter of time there. 2) A small rng cleanup to the self test harness to make it initialize faster on 5.18. 3) Wang reported and fixed a skb leak for CONFIG_IPV6=n. 4) After Wang's fix for the direct leak, I investigated how that code path even could be hit, and found that the netlink layer still handles IPv6 endpoints, when it probably shouldn't. ==================== Link: https://lore.kernel.org/r/20220330013127.426620-1-Jason@zx2c4.comSigned-off-by:
-
Jason A. Donenfeld authored
The previous commit fixed a memory leak on the send path in the event that IPv6 is disabled at compile time, but how did a packet even arrive there to begin with? It turns out we have previously allowed IPv6 endpoints even when IPv6 support is disabled at compile time. This is awkward and inconsistent. Instead, let's just ignore all things IPv6, the same way we do other malformed endpoints, in the case where IPv6 is disabled. Fixes: e7096c13 ("net: WireGuard secure network tunnel") Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Wang Hai authored
I got a memory leak report: unreferenced object 0xffff8881191fc040 (size 232): comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0 [<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340 [<ffffffff832974fb>] __alloc_skb+0x1db/0x200 [<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0 [<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110 [<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30 [<ffffffff8119c558>] process_one_work+0x2e8/0x770 [<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0 [<ffffffff811a88e0>] kthread+0x120/0x160 [<ffffffff8100242f>] ret_from_fork+0x1f/0x30 In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_ buffer_to_peer(), the semantics of send6() is required to free skb. But when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it to fix this bug. Signed-off-by:Wang Hai <wanghai38@huawei.com> Fixes: e7096c13 ("net: WireGuard secure network tunnel") Signed-off-by:
-
Jason A. Donenfeld authored
The seed_rng() function was written to work across lots of old kernels, back when WireGuard used a big compatibility layer. Now that things have evolved, we can vastly simplify this, by just marking the RNG as seeded. Signed-off-by:
-
Jason A. Donenfeld authored
We make too nuanced use of ptr_ring to entirely move to the skb_array wrappers, but we at least should avoid the naughty function pointer cast when cleaning up skbs. Otherwise RAP/CFI will honk at us. This patch uses the __skb_array_destroy_skb wrapper for the cleanup, rather than directly providing kfree_skb, which is what other drivers in the same situation do too. Reported-by:
PaX Team <pageexec@freemail.hu> Fixes: 886fcee9 ("wireguard: receive: use ring buffer for incoming handshakes") Signed-off-by:
-
- 30 Mar, 2022 4 commits
-
-
Martin Habets authored
On such systems cpumask_of_node() returns NULL, which bitmap operations are not happy with. Fixes: c265b569 ("sfc: default config to 1 channel/core in local NUMA node only") Fixes: 09a99ab1 ("sfc: set affinity hints in local NUMA node only") Signed-off-by:
Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by:
Íñigo Huguet <ihuguet@redhat.com> Link: https://lore.kernel.org/r/164857006953.8140.3265568858101821256.stgit@palantir17.mph.netSigned-off-by:
-
Jonathan Lemon authored
nvmem_device_find returns a valid pointer or IS_ERR(). Handle this properly. Fixes: 0cfcdd1e ("ptp: ocp: add nvmem interface for accessing eeprom") Signed-off-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Link: https://lore.kernel.org/r/20220329160354.4035-1-jonathan.lemon@gmail.comSigned-off-by:
-
Zheng Yongjun authored
As the possible failure of the allocation, kzalloc() may return NULL pointer. Therefore, it should be better to check the 'sgi' in order to prevent the dereference of NULL pointer. Fixes: 23ae3a78 ("net: dsa: felix: add stream gate settings for psfp"). Signed-off-by:
Zheng Yongjun <zhengyongjun3@huawei.com> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20220329090800.130106-1-zhengyongjun3@huawei.comSigned-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfJakub Kicinski authored
Alexei Starovoitov says: ==================== pull-request: bpf 2022-03-29 We've added 16 non-merge commits during the last 1 day(s) which contain a total of 24 files changed, 354 insertions(+), 187 deletions(-). The main changes are: 1) x86 specific bits of fprobe/rethook, from Masami and Peter. 2) ice/xsk fixes, from Maciej and Magnus. 3) Various small fixes, from Andrii, Yonghong, Geliang and others. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: selftests/bpf: Fix clang compilation errors ice: xsk: Fix indexing in ice_tx_xsk_pool() ice: xsk: Stop Rx processing when ntc catches ntu ice: xsk: Eliminate unnecessary loop iteration xsk: Do not write NULL in SW ring at allocation failure x86,kprobes: Fix optprobe trampoline to generate complete pt_regs x86,rethook: Fix arch_rethook_trampoline() to generate a complete pt_regs x86,rethook,kprobes: Replace kretprobe with rethook on x86 kprobes: Use rethook for kretprobe if possible bpftool: Fix generated code in codegen_asserts selftests/bpf: fix selftest after random: Urandom_read tracepoint removal bpf: Fix maximum permitted number of arguments check bpf: Sync comments for bpf_get_stack fprobe: Fix sparse warning for acccessing __rcu ftrace_hash fprobe: Fix smatch type mismatch warning bpf/bpftool: Add unprivileged_bpf_disabled check against value of 2 ==================== Link: https://lore.kernel.org/r/20220329234924.39053-1-alexei.starovoitov@gmail.comSigned-off-by:
-
- 29 Mar, 2022 15 commits
-
-
Vinod Koul authored
SM8150 has an ethernet controller and it needs a different configuration, so add a new compatible for this. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org> [bhsharma: Massage the commit log] Signed-off-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> Link: https://lore.kernel.org/r/20220325200731.1585554-1-bhupesh.sharma@linaro.orgSigned-off-by:
-
Michael Walle authored
ioctls handled by phy_mii_ioctl() will cause a kernel oops when the interface is down. Fix it by making sure there is a PHY attached. Fixes: 735fec99 ("net: lan966x: Implement SIOCSHWTSTAMP and SIOCGHWTSTAMP") Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
-
Paolo Abeni authored
Duoming Zhou says: ==================== Fix UAF bugs caused by ax25_release() The first patch fixes UAF bugs in ax25_send_control, and the second patch fixes UAF bugs in ax25 timers. ==================== Link: https://lore.kernel.org/r/cover.1648472006.git.duoming@zju.edu.cnSigned-off-by:
-
Duoming Zhou authored
There are race conditions that may lead to UAF bugs in ax25_heartbeat_expiry(), ax25_t1timer_expiry(), ax25_t2timer_expiry(), ax25_t3timer_expiry() and ax25_idletimer_expiry(), when we call ax25_release() to deallocate ax25_dev. One of the UAF bugs caused by ax25_release() is shown below: (Thread 1) | (Thread 2) ax25_dev_device_up() //(1) | ... | ax25_kill_by_device() ax25_bind() //(2) | ax25_connect() | ... ax25_std_establish_data_link() | ax25_start_t1timer() | ax25_dev_device_down() //(3) mod_timer(&ax25->t1timer,..) | | ax25_release() (wait a time) | ... | ax25_dev_put(ax25_dev) //(4)FREE ax25_t1timer_expiry() | ax25->ax25_dev->values[..] //USE| ... ... | We increase the refcount of ax25_dev in position (1) and (2), and decrease the refcount of ax25_dev in position (3) and (4). The ax25_dev will be freed in position (4) and be used in ax25_t1timer_expiry(). The fail log is shown below: ============================================================== [ 106.116942] BUG: KASAN: use-after-free in ax25_t1timer_expiry+0x1c/0x60 [ 106.116942] Read of size 8 at addr ffff88800bda9028 by task swapper/0/0 [ 106.116942] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-06123-g0905eec574 [ 106.116942] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-14 [ 106.116942] Call Trace: ... [ 106.116942] ax25_t1timer_expiry+0x1c/0x60 [ 106.116942] call_timer_fn+0x122/0x3d0 [ 106.116942] __run_timers.part.0+0x3f6/0x520 [ 106.116942] run_timer_softirq+0x4f/0xb0 [ 106.116942] __do_softirq+0x1c2/0x651 ... This patch adds del_timer_sync() in ax25_release(), which could ensure that all timers stop before we deallocate ax25_dev. Signed-off-by:Duoming Zhou <duoming@zju.edu.cn> Signed-off-by:
-
Duoming Zhou authored
There are UAF bugs in ax25_send_control(), when we call ax25_release() to deallocate ax25_dev. The possible race condition is shown below: (Thread 1) | (Thread 2) ax25_dev_device_up() //(1) | | ax25_kill_by_device() ax25_bind() //(2) | ax25_connect() | ... ax25->state = AX25_STATE_1 | ... | ax25_dev_device_down() //(3) (Thread 3) ax25_release() | ax25_dev_put() //(4) FREE | case AX25_STATE_1: | ax25_send_control() | alloc_skb() //USE | The refcount of ax25_dev increases in position (1) and (2), and decreases in position (3) and (4). The ax25_dev will be freed before dereference sites in ax25_send_control(). The following is part of the report: [ 102.297448] BUG: KASAN: use-after-free in ax25_send_control+0x33/0x210 [ 102.297448] Read of size 8 at addr ffff888009e6e408 by task ax25_close/602 [ 102.297448] Call Trace: [ 102.303751] ax25_send_control+0x33/0x210 [ 102.303751] ax25_release+0x356/0x450 [ 102.305431] __sock_release+0x6d/0x120 [ 102.305431] sock_close+0xf/0x20 [ 102.305431] __fput+0x11f/0x420 [ 102.305431] task_work_run+0x86/0xd0 [ 102.307130] get_signal+0x1075/0x1220 [ 102.308253] arch_do_signal_or_restart+0x1df/0xc00 [ 102.308253] exit_to_user_mode_prepare+0x150/0x1e0 [ 102.308253] syscall_exit_to_user_mode+0x19/0x50 [ 102.308253] do_syscall_64+0x48/0x90 [ 102.308253] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 102.308253] RIP: 0033:0x405ae7 This patch defers the free operation of ax25_dev and net_device after all corresponding dereference sites in ax25_release() to avoid UAF. Fixes: 9fd75b66 ("ax25: Fix refcount leaks caused by ax25_cb_del()") Signed-off-by: -
Martin Varghese authored
IPv6 nd target mask was not getting populated in flow dump. In the function __ovs_nla_put_key the icmp code mask field was checked instead of icmp code key field to classify the flow as neighbour discovery. ufid:bdfbe3e5-60c2-43b0-a5ff-dfcac1c37328, recirc_id(0),dp_hash(0/0), skb_priority(0/0),in_port(ovs-nm1),skb_mark(0/0),ct_state(0/0), ct_zone(0/0),ct_mark(0/0),ct_label(0/0), eth(src=00:00:00:00:00:00/00:00:00:00:00:00, dst=00:00:00:00:00:00/00:00:00:00:00:00), eth_type(0x86dd), ipv6(src=::/::,dst=::/::,label=0/0,proto=58,tclass=0/0,hlimit=0/0,frag=no), icmpv6(type=135,code=0), nd(target=2001::2/::, sll=00:00:00:00:00:00/00:00:00:00:00:00, tll=00:00:00:00:00:00/00:00:00:00:00:00), packets:10, bytes:860, used:0.504s, dp:ovs, actions:ovs-nm2 Fixes: e6445719 (openvswitch: Restructure datapath.c and flow.c) Signed-off-by:
Martin Varghese <martin.varghese@nokia.com> Link: https://lore.kernel.org/r/20220328054148.3057-1-martinvarghesenokia@gmail.comSigned-off-by:
-
Yonghong Song authored
llvm upstream patch ([1]) added to issue warning for code like void test() { int j = 0; for (int i = 0; i < 1000; i++) j++; return; } This triggered several errors in selftests/bpf build since compilation flag -Werror is used. ... test_lpm_map.c:212:15: error: variable 'n_matches' set but not used [-Werror,-Wunused-but-set-variable] size_t i, j, n_matches, n_matches_after_delete, n_nodes, n_lookups; ^ test_lpm_map.c:212:26: error: variable 'n_matches_after_delete' set but not used [-Werror,-Wunused-but-set-variable] size_t i, j, n_matches, n_matches_after_delete, n_nodes, n_lookups; ^ ... prog_tests/get_stack_raw_tp.c:32:15: error: variable 'cnt' set but not used [-Werror,-Wunused-but-set-variable] static __u64 cnt; ^ ... For test_lpm_map.c, 'n_matches'/'n_matches_after_delete' are changed to be volatile in order to silent the warning. I didn't remove these two declarations since they are referenced in a commented code which might be used by people in certain cases. For get_stack_raw_tp.c, the variable 'cnt' is removed. [1] https://reviews.llvm.org/D122271Signed-off-by:Yonghong Song <yhs@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20220325200304.2915588-1-yhs@fb.com
-
Alexei Starovoitov authored
Maciej Fijalkowski says: ==================== Hello, yet another fixes for XSK from Magnus and me. Magnus addresses the fact that xp_alloc() can return NULL, so this needs to be handled to avoid clearing entries in the SW ring on driver side. Then he addresses the off-by-one problem in Tx desc cleaning routine for ice ZC driver. From my side, I am adding protection to ZC Rx processing loop so that cleaning of descriptors wouldn't go over already processed entries. Then I also fix an issue with assigning XSK pool to Tx queues. This is directed to bpf tree. Thanks! Maciej Fijalkowski (2): ice: xsk: stop Rx processing when ntc catches ntu ice: xsk: fix indexing in ice_tx_xsk_pool() ==================== Acked-by:
Alexander Lobakin <alexandr.lobakin@intel.com> Signed-off-by:
-
Maciej Fijalkowski authored
Ice driver tries to always create XDP rings array to be num_possible_cpus() sized, regardless of user's queue count setting that can be changed via ethtool -L for example. Currently, ice_tx_xsk_pool() calculates the qid by decrementing the ring->q_index by the count of XDP queues, but ring->q_index is set to 'i + vsi->alloc_txq'. When user did ethtool -L $IFACE combined 1, alloc_txq is 1, but vsi->num_xdp_txq is still num_possible_cpus(). Then, ice_tx_xsk_pool() will do OOB access and in the final result ring would not get xsk_pool pointer assigned. Then, each ice_xsk_wakeup() call will fail with error and it will not be possible to get into NAPI and do the processing from driver side. Fix this by decrementing vsi->alloc_txq instead of vsi->num_xdp_txq from ring-q_index in ice_tx_xsk_pool() so the calculation is reflected to the setting of ring->q_index. Fixes: 22bf877e ("ice: introduce XDP_TX fallback path") Signed-off-by:
Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by:
-
Maciej Fijalkowski authored
This can happen with big budget values and some breakage of re-filling descriptors as we do not clear the entry that ntu is pointing at the end of ice_alloc_rx_bufs_zc. So if ntc is at ntu then it might be the case that status_error0 has an old, uncleared value and ntc would go over with processing which would result in false results. Break Rx loop when ntc == ntu to avoid broken behavior. Fixes: 3876ff52 ("ice: xsk: Handle SW XDP ring wrap and bump tail more often") Signed-off-by:
-
Magnus Karlsson authored
The NIC Tx ring completion routine cleans entries from the ring in batches. However, it processes one more batch than it is supposed to. Note that this does not matter from a functionality point of view since it will not find a set DD bit for the next batch and just exit the loop. But from a performance perspective, it is faster to terminate the loop before and not issue an expensive read over PCIe to get the DD bit. Fixes: 126cdfe1 ("ice: xsk: Improve AF_XDP ZC Tx and use batching API") Signed-off-by:
Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by:
-
Magnus Karlsson authored
For the case when xp_alloc_batch() is used but the batched allocation cannot be used, there is a slow path that uses the non-batched xp_alloc(). When it fails to allocate an entry, it returns NULL. The current code wrote this NULL into the entry of the provided results array (pointer to the driver SW ring usually) and returned. This might not be what the driver expects and to make things simpler, just write successfully allocated xdp_buffs into the SW ring,. The driver might have information in there that is still important after an allocation failure. Note that at this point in time, there are no drivers using xp_alloc_batch() that could trigger this slow path. But one might get added. Fixes: 47e4075d ("xsk: Batched buffer allocation for the pool") Signed-off-by:
-
Alexei Starovoitov authored
Masami Hiramatsu says: ==================== Here are the 3rd version for generic kretprobe and kretprobe on x86 for replacing the kretprobe trampoline with rethook. The previous version is here[1] [1] https://lore.kernel.org/all/164821817332.2373735.12048266953420821089.stgit@devnote2/T/#u This version fixed typo and build issues for bpf-next and CONFIG_RETHOOK=y error. I also add temporary mitigation lines for ANNOTATE_NOENDBR macro issue for bpf-next tree [2/4]. This will be removed after merging kernel IBT series. Background: This rethook came from Jiri's request of multiple kprobe for bpf[2]. He tried to solve an issue that starting bpf with multiple kprobe will take a long time because bpf-kprobe will wait for RCU grace period for sync rcu events. Jiri wanted to attach a single bpf handler to multiple kprobes and he tried to introduce multiple-probe interface to kprobe. So I asked him to use ftrace and kretprobe-like hook if it is only for the function entry and exit, instead of adding ad-hoc interface to kprobes. For this purpose, I introduced the fprobe (kprobe like interface for ftrace) with the rethook (this is a generic return hook feature for fprobe exit handler)[3]. [2] https://lore.kernel.org/all/20220104080943.113249-1-jolsa@kernel.org/T/#u [3] https://lore.kernel.org/all/164191321766.806991.7930388561276940676.stgit@devnote2/T/#u The rethook is basically same as the kretprobe trampoline. I just made it decoupled from kprobes. Eventually, the all arch dependent kretprobe trampolines will be replaced with the rethook trampoline instead of cloning and set HAVE_RETHOOK=y. When I port the rethook for all arch which supports kretprobe, the legacy kretprobe specific code (which is for CONFIG_KRETPROBE_ON_RETHOOK=n) will be removed eventually. ==================== Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
-
Masami Hiramatsu authored
Currently the optprobe trampoline template code ganerate an almost complete pt_regs on-stack, everything except regs->ss. The 'regs->ss' points to the top of stack, which is not a valid segment decriptor. As same as the rethook does, complete the job by also pushing ss. Suggested-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
-
Peter Zijlstra authored
Currently arch_rethook_trampoline() generates an almost complete pt_regs on-stack, everything except regs->ss that is, that currently points to the fake return address, which is not a valid segment descriptor. Since interpretation of regs->[sb]p should be done in the context of regs->ss, and we have code actually doing that (see arch/x86/lib/insn-eval.c for instance), complete the job by also pushing ss. This ensures that anybody who does do look at regs->ss doesn't mysteriously malfunction, avoiding much future pain. Signed-off-by:
-
