From 5b55633f20ee1bb253dc7d915ec2fd35fd865d5a Mon Sep 17 00:00:00 2001 From: Julian Wiedmann Date: Thu, 5 Dec 2019 14:33:02 +0100 Subject: s390/qeth: guard against runt packets Depending on a packet's type, the RX path needs to access fields in the packet headers and thus requires a minimum packet length. Enforce this length when building the skb. On the other hand a single runt packet is no reason to drop the whole RX buffer. So just skip it, and continue processing on the next packet. Fixes: 4a71df50047f ("qeth: new qeth device driver") Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller --- drivers/s390/net/qeth_core.h | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/s390/net/qeth_core.h') diff --git a/drivers/s390/net/qeth_core.h b/drivers/s390/net/qeth_core.h index 293dd99b7fef..7cdebd2e329f 100644 --- a/drivers/s390/net/qeth_core.h +++ b/drivers/s390/net/qeth_core.h @@ -480,6 +480,7 @@ struct qeth_card_stats { u64 rx_dropped_nomem; u64 rx_dropped_notsupp; + u64 rx_dropped_runt; /* rtnl_link_stats64 */ u64 rx_packets; -- cgit From f9e50b02a99c3ebbaa30690e8d5be28a5c2624eb Mon Sep 17 00:00:00 2001 From: Julian Wiedmann Date: Thu, 5 Dec 2019 14:33:04 +0100 Subject: s390/qeth: fix dangling IO buffers after halt/clear The cio layer's intparm logic does not align itself well with how qeth manages cmd IOs. When an active IO gets terminated via halt/clear, the corresponding IRQ's intparm does not reflect the cmd buffer but rather the intparm that was passed to ccw_device_halt() / ccw_device_clear(). This behaviour was recently clarified in commit b91d9e67e50b ("s390/cio: fix intparm documentation"). As a result, qeth_irq() currently doesn't cancel a cmd that was terminated via halt/clear. This primarily causes us to leak card->read_cmd after the qeth device is removed, since our IO path still holds a refcount for this cmd. For qeth this means that we need to keep track of which IO is pending on a device ('active_cmd'), and use this as the intparm when calling halt/clear. Otherwise qeth_irq() can't match the subsequent IRQ to its cmd buffer. Since we now keep track of the _expected_ intparm, we can also detect any mismatch; this would constitute a bug somewhere in the lower layers. In this case cancel the active cmd - we effectively "lost" the IRQ and should not expect any further notification for this IO. Fixes: 405548959cc7 ("s390/qeth: add support for dynamically allocated cmds") Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller --- drivers/s390/net/qeth_core.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/s390/net/qeth_core.h') diff --git a/drivers/s390/net/qeth_core.h b/drivers/s390/net/qeth_core.h index 7cdebd2e329f..871d44746f5c 100644 --- a/drivers/s390/net/qeth_core.h +++ b/drivers/s390/net/qeth_core.h @@ -628,6 +628,7 @@ struct qeth_ipato { struct qeth_channel { struct ccw_device *ccwdev; + struct qeth_cmd_buffer *active_cmd; enum qeth_channel_states state; atomic_t irq_pending; }; @@ -1038,6 +1039,8 @@ int qeth_do_run_thread(struct qeth_card *, unsigned long); void qeth_clear_thread_start_bit(struct qeth_card *, unsigned long); void qeth_clear_thread_running_bit(struct qeth_card *, unsigned long); int qeth_core_hardsetup_card(struct qeth_card *card, bool *carrier_ok); +int qeth_stop_channel(struct qeth_channel *channel); + void qeth_print_status_message(struct qeth_card *); int qeth_init_qdio_queues(struct qeth_card *); int qeth_send_ipa_cmd(struct qeth_card *, struct qeth_cmd_buffer *, -- cgit