Re: [PATCH v7 4/4] Bluetooth: btqca: inject command complete event during fw download
Hi Marcel,
On 2018-12-29 12:48, Marcel Holtmann wrote:
Hi Balakrishna,
Latest qualcomm chips are not sending an command complete event for
every firmware packet sent to chip. They only respond with a vendor
specific event for the last firmware packet. This optimization will
decrease the BT ON time. Due to this we are seeing a timeout error
message logs on the console during firmware download. Now we are
injecting a command complete event once we receive an vendor specific
event for the last RAM firmware packet.
Signed-off-by: Balakrishna Godavarthi
---
drivers/bluetooth/btqca.c | 39 ++-
drivers/bluetooth/btqca.h | 3 +++
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index ec9e03a6b778..0b533f65f652 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -144,6 +144,7 @@ static void qca_tlv_check_data(struct rome_config
*config,
* In case VSE is skipped, only the last segment is acked.
*/
config->dnld_mode = tlv_patch->download_mode;
+ config->dnld_type = config->dnld_mode;
BT_DBG("Total Length : %d bytes",
le32_to_cpu(tlv_patch->total_size));
@@ -264,6 +265,31 @@ static int qca_tlv_send_segment(struct hci_dev
*hdev, int seg_size,
return err;
}
+static int qca_inject_cmd_complete_event(struct hci_dev *hdev)
+{
+ struct hci_event_hdr *hdr;
+ struct hci_ev_cmd_complete *evt;
+ struct sk_buff *skb;
+
+ skb = bt_skb_alloc(sizeof(*hdr) + sizeof(*evt) + 1, GFP_KERNEL);
+ if (!skb)
+ return -ENOMEM;
+
+ hdr = skb_put(skb, sizeof(*hdr));
+ hdr->evt = HCI_EV_CMD_COMPLETE;
+ hdr->plen = sizeof(*evt) + 1;
+
+ evt = skb_put(skb, sizeof(*evt));
+ evt->ncmd = 1;
+ evt->opcode = HCI_OP_NOP;
+
+ skb_put_u8(skb, QCA_HCI_CC_SUCCESS);
+
+ hci_skb_pkt_type(skb) = HCI_EVENT_PKT;
+
+ return hci_recv_frame(hdev, skb);
+}
+
static int qca_download_firmware(struct hci_dev *hdev,
struct rome_config *config)
{
@@ -297,11 +323,22 @@ static int qca_download_firmware(struct hci_dev
*hdev,
ret = qca_tlv_send_segment(hdev, segsize, segment,
config->dnld_mode);
if (ret)
- break;
+ goto out;
segment += segsize;
}
+ /* Latest qualcomm chipsets are not sending a command complete event
+ * for every fw packet sent. They only respond with a vendor
specific
+* event for the last packet. This optimization in the chip will
+ * decrease the BT in initialization time. Here we will inject a
command
+* complete event to avoid a command timeout error message.
+*/
+ if ((config->dnld_type == ROME_SKIP_EVT_VSE_CC ||
+ config->dnld_type == ROME_SKIP_EVT_VSE))
+ return qca_inject_cmd_complete_event(hdev);
+
have you actually considered using __hci_cmd_send in that case. It is
allowed for vendor OGF to use that command. I see you actually do use
it and now I am failing to understand what this is for.
[Bala]: thanks for reviewing the change.
__hci_cmd_send() can be used only to send the command to the chip. it
will not wait for the response for the command sent.
as you know that every vendor command sent to chip will respond with
vendor specific event and command complete event.
but in our case chip will only respond with vendor specific event only.
so we are injecting command complete event.
Regards
Marcel
--
Regards
Balakrishna.
Re: [PATCH v2 5/5] usb:cdns3 Add Cadence USB3 DRD Driver
hi,
On Sun, 2018-12-23 at 15:13 +, Pawel Laszczak wrote:
> This patch introduce new Cadence USBSS DRD driver
> to linux kernel.
<...>
> diff --git a/drivers/usb/cdns3/cdns3-pci-wrap.c
> b/drivers/usb/cdns3/cdns3-pci-wrap.c
> new file mode 100644
> index ..e93179c45ece
> --- /dev/null
> +++ b/drivers/usb/cdns3/cdns3-pci-wrap.c
> @@ -0,0 +1,157 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Cadence USBSS PCI Glue driver
> + *
> + * Copyright (C) 2018 Cadence.
> + *
> + * Author: Pawel Laszczak
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct cdns3_wrap {
> + struct platform_device *plat_dev;
> + struct pci_dev *hg_dev;
> + struct resource dev_res[4];
> +};
> +
> +struct cdns3_wrap wrap;
> +
> +#define RES_IRQ_ID 0
> +#define RES_HOST_ID 1
> +#define RES_DEV_ID 2
> +#define RES_DRD_ID 3
> +
> +#define PCI_BAR_HOST 0
> +#define PCI_BAR_DEV 2
> +#define PCI_BAR_OTG 4
> +
> +#define PCI_DEV_FN_HOST_DEVICE 0
> +#define PCI_DEV_FN_OTG 1
> +
> +#define PCI_DRIVER_NAME "cdns3-pci-usbss"
> +#define PLAT_DRIVER_NAME "cdns-usb3"
> +
> +#define CDNS_VENDOR_ID 0x17cd
> +#define CDNS_DEVICE_ID 0x0100
> +
> +/**
> + * cdns3_pci_probe - Probe function for Cadence USB wrapper driver
> + * @pdev: platform device object
> + * @id: pci device id
> + *
> + * Returns 0 on success otherwise negative errno
> + */
> +static int cdns3_pci_probe(struct pci_dev *pdev,
> +const struct pci_device_id *id)
> +{
> + struct platform_device_info plat_info;
> + struct cdns3_wrap *wrap;
> + struct resource *res;
> + int err;
> +
> + /*
> + * for GADGET/HOST PCI (devfn) function number is 0,
> + * for OTG PCI (devfn) function number is 1
> + */
> + if (!id || pdev->devfn != PCI_DEV_FN_HOST_DEVICE)
> + return -EINVAL;
> +
> + err = pcim_enable_device(pdev);
> + if (err) {
> + dev_err(>dev, "Enabling PCI device has failed %d\n", err);
> + return err;
> + }
> +
> + pci_set_master(pdev);
> + wrap = devm_kzalloc(>dev, sizeof(*wrap), GFP_KERNEL);
> + if (!wrap) {
> + dev_err(>dev, "Failed to allocate memory\n");
> + return -ENOMEM;
> + }
> +
> + /* function 0: host(BAR_0) + device(BAR_1) + otg(BAR_2)). */
> + memset(wrap->dev_res, 0x00,
> +sizeof(struct resource) * ARRAY_SIZE(wrap->dev_res));
> + dev_dbg(>dev, "Initialize Device resources\n");
> + res = wrap->dev_res;
> +
> + res[RES_DEV_ID].start = pci_resource_start(pdev, PCI_BAR_DEV);
> + res[RES_DEV_ID].end = pci_resource_end(pdev, PCI_BAR_DEV);
> + res[RES_DEV_ID].name = "cdns3-dev-regs";
> + res[RES_DEV_ID].flags = IORESOURCE_MEM;
> + dev_dbg(>dev, "USBSS-DEV physical base addr: %pa\n",
> + [RES_DEV_ID].start);
> +
> + res[RES_HOST_ID].start = pci_resource_start(pdev, PCI_BAR_HOST);
> + res[RES_HOST_ID].end = pci_resource_end(pdev, PCI_BAR_HOST);
> + res[RES_HOST_ID].name = "cdns3-xhci-regs";
> + res[RES_HOST_ID].flags = IORESOURCE_MEM;
> + dev_dbg(>dev, "USBSS-XHCI physical base addr: %pa\n",
> + [RES_HOST_ID].start);
> +
> + res[RES_DRD_ID].start = pci_resource_start(pdev, PCI_BAR_OTG);
> + res[RES_DRD_ID].end = pci_resource_end(pdev, PCI_BAR_OTG);
> + res[RES_DRD_ID].name = "cdns3-otg";
> + res[RES_DRD_ID].flags = IORESOURCE_MEM;
> + dev_dbg(>dev, "USBSS-DRD physical base addr: %pa\n",
> + [RES_DRD_ID].start);
> +
> + /* Interrupt common for both device and XHCI */
> + wrap->dev_res[RES_IRQ_ID].start = pdev->irq;
> + wrap->dev_res[RES_IRQ_ID].name = "cdns3-irq";
> + wrap->dev_res[RES_IRQ_ID].flags = IORESOURCE_IRQ;
> +
> + /* set up platform device info */
> + memset(_info, 0, sizeof(plat_info));
> + plat_info.parent = >dev;
> + plat_info.fwnode = pdev->dev.fwnode;
> + plat_info.name = PLAT_DRIVER_NAME;
> + plat_info.id = pdev->devfn;
> + plat_info.res = wrap->dev_res;
> + plat_info.num_res = ARRAY_SIZE(wrap->dev_res);
> + plat_info.dma_mask = pdev->dma_mask;
> +
> + /* register platform device */
> + wrap->plat_dev = platform_device_register_full(_info);
> + if (IS_ERR(wrap->plat_dev)) {
> + err = PTR_ERR(wrap->plat_dev);
> + return err;
> + }
return PTR_ERR(wrap->plat_dev);
> +
> + pci_set_drvdata(pdev, wrap);
> +
> + return err;
> +}
> +
> +void cdns3_pci_remove(struct pci_dev *pdev)
> +{
> + struct cdns3_wrap *wrap = (struct cdns3_wrap *)pci_get_drvdata(pdev);
> +
> + platform_device_unregister(wrap->plat_dev);
> +}
> +
> +static const struct pci_device_id cdns3_pci_ids[] = {
> + { PCI_DEVICE(CDNS_VENDOR_ID, CDNS_DEVICE_ID), },
> + { 0, }
> +};
> +
> +static struct pci_driver cdns3_pci_driver = {
> +
Re: [PATCH] netfilter: account ebt_table_info to kmemcg
On Fri 28-12-18 17:55:24, Shakeel Butt wrote:
> The [ip,ip6,arp]_tables use x_tables_info internally and the underlying
> memory is already accounted to kmemcg. Do the same for ebtables. The
> syzbot, by using setsockopt(EBT_SO_SET_ENTRIES), was able to OOM the
> whole system from a restricted memcg, a potential DoS.
What is the lifetime of these objects? Are they bound to any process?
> Reported-by: syzbot+7713f3aa67be76b15...@syzkaller.appspotmail.com
> Signed-off-by: Shakeel Butt
> ---
> net/bridge/netfilter/ebtables.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
> index 491828713e0b..5e55cef0cec3 100644
> --- a/net/bridge/netfilter/ebtables.c
> +++ b/net/bridge/netfilter/ebtables.c
> @@ -1137,14 +1137,16 @@ static int do_replace(struct net *net, const void
> __user *user,
> tmp.name[sizeof(tmp.name) - 1] = 0;
>
> countersize = COUNTER_OFFSET(tmp.nentries) * nr_cpu_ids;
> - newinfo = vmalloc(sizeof(*newinfo) + countersize);
> + newinfo = __vmalloc(sizeof(*newinfo) + countersize, GFP_KERNEL_ACCOUNT,
> + PAGE_KERNEL);
> if (!newinfo)
> return -ENOMEM;
>
> if (countersize)
> memset(newinfo->counters, 0, countersize);
>
> - newinfo->entries = vmalloc(tmp.entries_size);
> + newinfo->entries = __vmalloc(tmp.entries_size, GFP_KERNEL_ACCOUNT,
> + PAGE_KERNEL);
> if (!newinfo->entries) {
> ret = -ENOMEM;
> goto free_newinfo;
> --
> 2.20.1.415.g653613c723-goog
>
--
Michal Hocko
SUSE Labs
Re: [RFC,v2] Bluetooth: hci_qca: Collect controller memory dump during SSR
Hi Balakrishna,
> We will collect the ramdump of BT controller when hardware error event
> received before rebooting the HCI layer. Before restarting a subsystem
> or a process running on a subsystem, it is often required to request
> either a subsystem or a process to perform proper cache dump and
> software failure reason into a memory buffer which application
> processor can retrieve afterwards. SW developers can often provide
> initial investigation by looking into that debugging information.
>
> Signed-off-by: Balakrishna Godavarthi
> ---
> changes v2:
> * entirely an newer approach handling with an work queue.
>
> ---
> drivers/bluetooth/hci_qca.c | 289 ++--
> 1 file changed, 278 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index f036c8f98ea3..62b768bc32ec 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
don't we have some crashdump core facility that could be utilized here?
> @@ -57,9 +58,10 @@
> /* Controller states */
> #define STATE_IN_BAND_SLEEP_ENABLED 1
>
> -#define IBS_WAKE_RETRANS_TIMEOUT_MS 100
> +#define IBS_WAKE_RETRANS_TIMEOUT_MS 100
> #define IBS_TX_IDLE_TIMEOUT_MS2000
> -#define BAUDRATE_SETTLE_TIMEOUT_MS 300
> +#define BAUDRATE_SETTLE_TIMEOUT_MS 300
> +#define MEMDUMP_COLLECTION_TIMEOUT_MS8000
>
> /* susclk rate */
> #define SUSCLK_RATE_32KHZ 32768
> @@ -67,6 +69,13 @@
> /* Controller debug log header */
> #define QCA_DEBUG_HANDLE 0x2EDC
>
> +/* Controller dump header */
> +#define QCA_SSR_DUMP_HANDLE 0x0108
> +#define QCA_DUMP_PACKET_SIZE 255
> +#define QCA_LAST_SEQUENCE_NUM0x
> +#define QCA_CRASHBYTE_PACKET_LEN 1100
> +#define QCA_MEMDUMP_BYTE 0xFB
> +
> /* HCI_IBS transmit side sleep protocol states */
> enum tx_ibs_states {
> HCI_IBS_TX_ASLEEP,
> @@ -89,12 +98,41 @@ enum hci_ibs_clock_state_vote {
> HCI_IBS_RX_VOTE_CLOCK_OFF,
> };
>
> +/* Controller memory dump states */
> +enum qca_memdump_states {
> + QCA_MEMDUMP_IDLE,
> + QCA_MEMDUMP_COLLECTING,
> + QCA_MEMDUMP_COLLECTED,
> + QCA_MEMDUMP_TIMEOUT,
> +};
> +
> +struct qca_memdump_data {
> + char *memdump_buf_head;
> + char *memdump_buf_tail;
> + u32 current_seq_no;
> + u32 received_dump;
> +};
> +
> +struct qca_memdump_event_hdr {
> + __u8evt;
> + __u8plen;
> + __u16 opcode;
> + __u16 seq_no;
> + __u8reserved;
> +} __packed;
> +
> +
> +struct qca_dump_size {
> + u32 dump_size;
> +} __packed;
> +
> struct qca_data {
> struct hci_uart *hu;
> struct sk_buff *rx_skb;
> struct sk_buff_head txq;
> - struct sk_buff_head tx_wait_q; /* HCI_IBS wait queue */
> - spinlock_t hci_ibs_lock;/* HCI_IBS state lock */
> + struct sk_buff_head tx_wait_q; /* HCI_IBS wait queue */
> + struct sk_buff_head rx_memdump_q; /* Memdump wait queue */
> + spinlock_t hci_ibs_lock;/* HCI_IBS state lock */
> u8 tx_ibs_state;/* HCI_IBS transmit side power state*/
> u8 rx_ibs_state;/* HCI_IBS receive side power state */
> bool tx_vote; /* Clock must be on for TX */
> @@ -103,12 +141,17 @@ struct qca_data {
> u32 tx_idle_delay;
> struct timer_list wake_retrans_timer;
> u32 wake_retrans;
> + struct timer_list memdump_timer;
> + u32 memdump_delay;
> struct workqueue_struct *workqueue;
> struct work_struct ws_awake_rx;
> struct work_struct ws_awake_device;
> struct work_struct ws_rx_vote_off;
> struct work_struct ws_tx_vote_off;
> + struct work_struct ctrl_memdump_evt;
> + struct qca_memdump_data *qca_memdump;
> unsigned long flags;
> + enum qca_memdump_states memdump_state;
>
> /* For debugging purpose */
> u64 ibs_sent_wacks;
> @@ -173,6 +216,7 @@ struct qca_serdev {
> static int qca_power_setup(struct hci_uart *hu, bool on);
> static void qca_power_shutdown(struct hci_uart *hu);
> static int qca_power_off(struct hci_dev *hdev);
> +static void qca_controller_memdump(struct work_struct *work);
>
> static void __serial_clock_on(struct tty_struct *tty)
> {
> @@ -446,6 +490,21 @@ static void hci_ibs_wake_retrans_timeout(struct
> timer_list *t)
> hci_uart_tx_wakeup(hu);
> }
>
> +static void hci_memdump_timeout(struct timer_list *t)
> +{
> + struct qca_data *qca = from_timer(qca, t, tx_idle_timer);
> + struct hci_uart *hu = qca->hu;
> + struct qca_memdump_data *qca_memdump = qca->qca_memdump;
> + char *memdump_buf = qca_memdump->memdump_buf_tail;
> +
> + bt_dev_err(hu->hdev, "clearing allocated memory due to memdump
> timeout");
> + kfree(memdump_buf);
> + kfree(qca_memdump);
> +
Re: [PATCH v5 1/6] net: lorawan: Add LoRaWAN socket module
Hi Jian-Hong,
Am 16.12.18 um 11:18 schrieb Jian-Hong Pan:
> This patch adds a new address/protocol family for LoRaWAN network.
> It also implements the the functions and maps to Datagram socket for
> LoRaWAN unconfirmed data messages.
>
> Signed-off-by: Jian-Hong Pan
[...]
> include/linux/lora/lorawan_netdev.h | 52 +++
> net/lorawan/Kconfig | 10 +
> net/lorawan/Makefile| 2 +
> net/lorawan/socket.c| 686
> 4 files changed, 750 insertions(+)
> create mode 100644 include/linux/lora/lorawan_netdev.h
> create mode 100644 net/lorawan/Kconfig
> create mode 100644 net/lorawan/Makefile
> create mode 100644 net/lorawan/socket.c
I'm not 100% happy with this yet, but to decouple it from the soft-MAC
discussion (patches 2-6/6) and to allow reuse by Ben, I've staged it in
linux-lora.git.
We can clean it up with incremental patches there (and squash later).
>
> diff --git a/include/linux/lora/lorawan_netdev.h
> b/include/linux/lora/lorawan_netdev.h
> new file mode 100644
> index ..5bffb5164f95
> --- /dev/null
> +++ b/include/linux/lora/lorawan_netdev.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
Is there any practical reason you dual-license your code? My LoRa code
is only GPL - should I reconsider that?
> +/*-
I assume the dash is a typo?
> + * LoRaWAN stack related definitions
> + *
> + * Copyright (c) 2018 Jian-Hong, Pan
> + *
Leftover white line from old license header?
> + */
> +
> +#ifndef __LORAWAN_NET_DEVICE_H__
> +#define __LORAWAN_NET_DEVICE_H__
> +
> +enum {
> + LRW_ADDR_APPEUI,
> + LRW_ADDR_DEVEUI,
> + LRW_ADDR_DEVADDR,
> +};
> +
> +struct lrw_addr_in {
> + int addr_type;
> + union {
> + u64 app_eui;
> + u64 dev_eui;
In my RFC and in linux-lora.git I have a lora_eui typedef - any reason
you're not using it here?
> + u32 devaddr;
> + };
> +};
> +
> +struct sockaddr_lorawan {
> + sa_family_t family; /* AF_LORAWAN */
> + struct lrw_addr_in addr_in;
> +};
> +
> +/**
> + * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
> + *
> + * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
> + */
> +struct lrw_mac_cb {
> + u32 devaddr;
> +};
> +
> +/**
> + * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
> + * @skb: the exchanging sk_buff
> + *
> + * Return: the pointer of LoRaWAN MAC control buffer
> + */
> +static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
> +{
> + return (struct lrw_mac_cb *)skb->cb;
> +}
For LoRa I have a separate lora/skb.h - suggest to split this off into
its own header consistently.
> +
> +#endif
> diff --git a/net/lorawan/Kconfig b/net/lorawan/Kconfig
> new file mode 100644
> index ..bf6c9b77573b
> --- /dev/null
> +++ b/net/lorawan/Kconfig
> @@ -0,0 +1,10 @@
> +config LORAWAN
> + tristate "LoRaWAN Network support"
The N in LoRaWAN is already for Network. :)
> + help
> + LoRaWAN defines low data rate, low power and long range wireless
> + wide area networks. It was designed to organize networks of automation
> + devices, such as sensors, switches and actuators. It can operate
> + multiple kilometers wide.
The missing information here to distinguish it from LoRa would be that
it's a client/server technology centered around gateways. In particular
gateways that anyone can run, distinguishing it from (Sigfox or) NB-IoT.
> +
> + Say Y here to compile LoRaWAN support into the kernel or say M to
> + compile it as a module.
> diff --git a/net/lorawan/Makefile b/net/lorawan/Makefile
> new file mode 100644
> index ..8c923ca6541a
> --- /dev/null
> +++ b/net/lorawan/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_LORAWAN)+= lorawan.o
> +lorawan-objs := socket.o
Both Kconfig and Makefile are not integrated into net/ here. That
happens only in 6/6.
> diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
> new file mode 100644
> index ..7ef106b877ca
> --- /dev/null
> +++ b/net/lorawan/socket.c
> @@ -0,0 +1,686 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
> +/*-
?
> + * LoRaWAN stack related definitions
> + *
> + * Copyright (c) 2018 Jian-Hong, Pan
> + *
?
> + */
> +
> +#define LORAWAN_MODULE_NAME "lorawan"
> +
> +#define pr_fmt(fmt) LORAWAN_MODULE_NAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include/* For TIOCOUTQ/INQ */
> +#include
> +#include
Please sort headers alphabetically.
> +
> +/**
> + * dgram_sock - This structure holds the states of Datagram socket
> + *
> + * @sk: network layer representation of the socket
> + * sk must be the first member of dgram_sock
Might that sentence be more useful as inline comment below?
> + * @src_devaddr: the
Re: [PATCH v7 4/4] Bluetooth: btqca: inject command complete event during fw download
Hi Balakrishna,
> Latest qualcomm chips are not sending an command complete event for
> every firmware packet sent to chip. They only respond with a vendor
> specific event for the last firmware packet. This optimization will
> decrease the BT ON time. Due to this we are seeing a timeout error
> message logs on the console during firmware download. Now we are
> injecting a command complete event once we receive an vendor specific
> event for the last RAM firmware packet.
>
> Signed-off-by: Balakrishna Godavarthi
> ---
> drivers/bluetooth/btqca.c | 39 ++-
> drivers/bluetooth/btqca.h | 3 +++
> 2 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> index ec9e03a6b778..0b533f65f652 100644
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -144,6 +144,7 @@ static void qca_tlv_check_data(struct rome_config *config,
>* In case VSE is skipped, only the last segment is acked.
>*/
> config->dnld_mode = tlv_patch->download_mode;
> + config->dnld_type = config->dnld_mode;
>
> BT_DBG("Total Length : %d bytes",
> le32_to_cpu(tlv_patch->total_size));
> @@ -264,6 +265,31 @@ static int qca_tlv_send_segment(struct hci_dev *hdev,
> int seg_size,
> return err;
> }
>
> +static int qca_inject_cmd_complete_event(struct hci_dev *hdev)
> +{
> + struct hci_event_hdr *hdr;
> + struct hci_ev_cmd_complete *evt;
> + struct sk_buff *skb;
> +
> + skb = bt_skb_alloc(sizeof(*hdr) + sizeof(*evt) + 1, GFP_KERNEL);
> + if (!skb)
> + return -ENOMEM;
> +
> + hdr = skb_put(skb, sizeof(*hdr));
> + hdr->evt = HCI_EV_CMD_COMPLETE;
> + hdr->plen = sizeof(*evt) + 1;
> +
> + evt = skb_put(skb, sizeof(*evt));
> + evt->ncmd = 1;
> + evt->opcode = HCI_OP_NOP;
> +
> + skb_put_u8(skb, QCA_HCI_CC_SUCCESS);
> +
> + hci_skb_pkt_type(skb) = HCI_EVENT_PKT;
> +
> + return hci_recv_frame(hdev, skb);
> +}
> +
> static int qca_download_firmware(struct hci_dev *hdev,
> struct rome_config *config)
> {
> @@ -297,11 +323,22 @@ static int qca_download_firmware(struct hci_dev *hdev,
> ret = qca_tlv_send_segment(hdev, segsize, segment,
> config->dnld_mode);
> if (ret)
> - break;
> + goto out;
>
> segment += segsize;
> }
>
> + /* Latest qualcomm chipsets are not sending a command complete event
> + * for every fw packet sent. They only respond with a vendor specific
> + * event for the last packet. This optimization in the chip will
> + * decrease the BT in initialization time. Here we will inject a command
> + * complete event to avoid a command timeout error message.
> + */
> + if ((config->dnld_type == ROME_SKIP_EVT_VSE_CC ||
> + config->dnld_type == ROME_SKIP_EVT_VSE))
> + return qca_inject_cmd_complete_event(hdev);
> +
have you actually considered using __hci_cmd_send in that case. It is allowed
for vendor OGF to use that command. I see you actually do use it and now I am
failing to understand what this is for.
Regards
Marcel
[PATCH v3 4/5] drm/bridge: lvds-encoder: add dev helper variable in .probe()
Make the code easier to read and modify.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 75b0d3f6e4de..f6770e83d49d 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -34,48 +34,47 @@ static struct drm_bridge_funcs funcs = {
static int lvds_encoder_probe(struct platform_device *pdev)
{
+ struct device *dev = >dev;
struct device_node *port;
struct device_node *endpoint;
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_encoder *lvds_encoder;
- lvds_encoder = devm_kzalloc(>dev, sizeof(*lvds_encoder),
- GFP_KERNEL);
+ lvds_encoder = devm_kzalloc(dev, sizeof(*lvds_encoder), GFP_KERNEL);
if (!lvds_encoder)
return -ENOMEM;
/* Locate the panel DT node. */
- port = of_graph_get_port_by_id(pdev->dev.of_node, 1);
+ port = of_graph_get_port_by_id(dev->of_node, 1);
if (!port) {
- dev_dbg(>dev, "port 1 not found\n");
+ dev_dbg(dev, "port 1 not found\n");
return -ENXIO;
}
endpoint = of_get_child_by_name(port, "endpoint");
of_node_put(port);
if (!endpoint) {
- dev_dbg(>dev, "no endpoint for port 1\n");
+ dev_dbg(dev, "no endpoint for port 1\n");
return -ENXIO;
}
panel_node = of_graph_get_remote_port_parent(endpoint);
of_node_put(endpoint);
if (!panel_node) {
- dev_dbg(>dev, "no remote endpoint for port 1\n");
+ dev_dbg(dev, "no remote endpoint for port 1\n");
return -ENXIO;
}
panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
if (!panel) {
- dev_dbg(>dev, "panel not found, deferring probe\n");
+ dev_dbg(dev, "panel not found, deferring probe\n");
return -EPROBE_DEFER;
}
lvds_encoder->panel_bridge =
- devm_drm_panel_bridge_add(>dev,
- panel, DRM_MODE_CONNECTOR_LVDS);
+ devm_drm_panel_bridge_add(dev, panel, DRM_MODE_CONNECTOR_LVDS);
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
@@ -83,7 +82,7 @@ static int lvds_encoder_probe(struct platform_device *pdev)
* but we need a bridge attached to our of_node for our user
* to look up.
*/
- lvds_encoder->bridge.of_node = pdev->dev.of_node;
+ lvds_encoder->bridge.of_node = dev->of_node;
lvds_encoder->bridge.funcs =
drm_bridge_add(_encoder->bridge);
--
2.11.0
[PATCH v3 3/5] dt-bindings: display: bridge: thc63lvdm83d: use standard powerdown-gpios
The name powerdown-gpios is the standard property name for the functionality covered by the previous pwdn-gpios name. This rename should be safe to do since the linux driver supporting the binding (lvds-encoder.c) never implemented the property, and no dts file names it. At least not upstream. Signed-off-by: Peter Rosin --- Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt index 527e236e9a2a..fee3c88e1a17 100644 --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt @@ -10,7 +10,7 @@ Required properties: Optional properties: -- pwdn-gpios: Power down control GPIO +- powerdown-gpios: Power down control GPIO (the /PWDN pin, active low). Required nodes: -- 2.11.0
[PATCH v3 5/5] drm/bridge: lvds-encoder: add powerdown-gpios support
Optionally power down the LVDS-encoder when it is not in use.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index f6770e83d49d..36d8557bc097 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -11,11 +11,13 @@
#include
#include
+#include
#include
struct lvds_encoder {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
+ struct gpio_desc *powerdown_gpio;
};
static int lvds_encoder_attach(struct drm_bridge *bridge)
@@ -28,8 +30,30 @@ static int lvds_encoder_attach(struct drm_bridge *bridge)
bridge);
}
+static void lvds_encoder_enable(struct drm_bridge *bridge)
+{
+ struct lvds_encoder *lvds_encoder = container_of(bridge,
+struct lvds_encoder,
+bridge);
+
+ if (lvds_encoder->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_encoder->powerdown_gpio, 0);
+}
+
+static void lvds_encoder_disable(struct drm_bridge *bridge)
+{
+ struct lvds_encoder *lvds_encoder = container_of(bridge,
+struct lvds_encoder,
+bridge);
+
+ if (lvds_encoder->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_encoder->powerdown_gpio, 1);
+}
+
static struct drm_bridge_funcs funcs = {
.attach = lvds_encoder_attach,
+ .enable = lvds_encoder_enable,
+ .disable = lvds_encoder_disable,
};
static int lvds_encoder_probe(struct platform_device *pdev)
@@ -45,6 +69,16 @@ static int lvds_encoder_probe(struct platform_device *pdev)
if (!lvds_encoder)
return -ENOMEM;
+ lvds_encoder->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(lvds_encoder->powerdown_gpio)) {
+ int err = PTR_ERR(lvds_encoder->powerdown_gpio);
+
+ if (err != -EPROBE_DEFER)
+ dev_err(dev, "powerdown GPIO failure: %d\n", err);
+ return err;
+ }
+
/* Locate the panel DT node. */
port = of_graph_get_port_by_id(dev->of_node, 1);
if (!port) {
--
2.11.0
[PATCH v3 1/5] dt-bindings: display: bridge: fork out ti,ds90c185 from lvds-transmitter
DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
binding, which is meant to be generic.
The sister chip DS90C187 is similar to DS90C185, describe it here as well.
Signed-off-by: Peter Rosin
---
.../bindings/display/bridge/lvds-transmitter.txt | 8 +---
.../bindings/display/bridge/ti,ds90c185.txt| 55 ++
2 files changed, 56 insertions(+), 7 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index 50220190c203..fd39ad34c383 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -22,13 +22,7 @@ among others.
Required properties:
-- compatible: Must be one or more of the following
- - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
- - "lvds-encoder" for a generic LVDS encoder device
-
- When compatible with the generic version, nodes must list the
- device-specific version corresponding to the device first
- followed by the generic version.
+- compatible: Must be "lvds-encoder"
Required nodes:
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
new file mode 100644
index ..e575f996959a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
@@ -0,0 +1,55 @@
+Texas Instruments FPD-Link (LVDS) Serializer
+
+
+The DS90C185 and DS90C187 are low-power serializers for portable
+battery-powered applications that reduces the size of the RGB
+interface between the host GPU and the display.
+
+Required properties:
+
+- compatible: Should be
+ "ti,ds90c185", "lvds-encoder" for the TI DS90C185 FPD-Link Serializer
+ "ti,ds90c187", "lvds-encoder" for the TI DS90C187 FPD-Link Serializer
+
+Optional properties:
+
+- powerdown-gpios: Power down control GPIO (the PDB pin, active-low)
+
+Required nodes:
+
+The devices have two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for parallel input
+- Video port 1 for LVDS output
+
+
+Example
+---
+
+lvds-encoder {
+ compatible = "ti,ds90c185", "lvds-encoder";
+
+ powerdown-gpios = < 17 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_enc_in: endpoint {
+ remote-endpoint = <_out_rgb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lvds_enc_out: endpoint {
+ remote-endpoint = <_panel_in>;
+ };
+ };
+ };
+};
--
2.11.0
[PATCH v3 2/5] dt-bindings: display: bridge: lvds-transmitter: cleanup example
Drop #address-cells and #size-cells from the root node in the
example, they are unused.
Reviewed-by: Rob Herring
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 2 --
1 file changed, 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index fd39ad34c383..36ce07c8d8e6 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -38,8 +38,6 @@ Example
lvds-encoder {
compatible = "lvds-encoder";
- #address-cells = <1>;
- #size-cells = <0>;
ports {
#address-cells = <1>;
--
2.11.0
[PATCH v3 0/5] drm/bridge: various small lvds-encoder things
Hi! I'm not sure if I should have added the texas chips to the lvds_encoder_match list in the driver, right next to the thine,thc63lvdm83d entry, but ended up not doing that. That can always be added later, if needed... Changes since v2: - changed from pwdn-gpios to powerdown-gpios after discussion with Rob with new patch 3/5 updating the thine,thc63lvdm83d binding as well as a consequence - added patch 4/5 which helps keep lines shorter in the lvds-encoder driver - added tag from Rob on patch 2/5 Changes since v1: - fork out the bindings for the texas chips into their own file in order to avoid clutter in the generic lvds-transmitter binding. - added a patch to remove some surplus stuff in the generic lvds-transmitter binding. Cheers, Peter Peter Rosin (5): dt-bindings: display: bridge: fork out ti,ds90c185 from lvds-transmitter dt-bindings: display: bridge: lvds-transmitter: cleanup example dt-bindings: display: bridge: thc63lvdm83d: use standard powerdown-gpios drm/bridge: lvds-encoder: add dev helper variable in .probe() drm/bridge: lvds-encoder: add powerdown-gpios support .../bindings/display/bridge/lvds-transmitter.txt | 10 +--- .../bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +- .../bindings/display/bridge/ti,ds90c185.txt| 55 ++ drivers/gpu/drm/bridge/lvds-encoder.c | 53 + 4 files changed, 100 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt -- 2.11.0
[PATCH] scripts: coccinelle: boolinit: drop warnings on named constants
Coccinelle doesn't always have access to the values of named
(#define) constants, and they may likely often be bound to true
and false values anyway, resulting in false positives. So stop
warning about them.
Signed-off-by: Julia Lawall
---
scripts/coccinelle/misc/boolinit.cocci |5 +
1 file changed, 5 insertions(+)
diff --git a/scripts/coccinelle/misc/boolinit.cocci
b/scripts/coccinelle/misc/boolinit.cocci
index b0584a3..aabb581 100644
--- a/scripts/coccinelle/misc/boolinit.cocci
+++ b/scripts/coccinelle/misc/boolinit.cocci
@@ -136,9 +136,14 @@ position p1;
@r4 depends on !patch@
bool b;
position p2;
+identifier i;
constant c != {0,1};
@@
+(
+ b = i
+|
*b@p2 = c
+)
@script:python depends on org@
p << r1.p;
Re: [PATCH] ipv4: fib_rules: Fix possible infinite loop in fib_empty_table
On 2018/12/29 13:15, David Miller wrote:
> From: YueHaibing
> Date: Wed, 26 Dec 2018 16:34:20 +0800
>
>> diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
>> index f8eb78d..1567e12 100644
>> --- a/net/ipv4/fib_rules.c
>> +++ b/net/ipv4/fib_rules.c
>> @@ -200,9 +200,13 @@ static struct fib_table *fib_empty_table(struct net
>> *net)
>> {
>> u32 id;
>>
>> -for (id = 1; id <= RT_TABLE_MAX; id++)
>> +for (id = 1; id <= RT_TABLE_MAX; id++) {
>> if (!fib_get_table(net, id))
>> return fib_new_table(net, id);
>> +
>> +if (id == RT_TABLE_MAX)
>> +break;
>> +}
>> return NULL;
>> }
>
> The loop now has two exit conditions, one of which (by your analysis
> is completely impossible).
>
Thanks, will do it in v2.
> Please clean this up into a loop with better structure and no
> impossible tests. One approach could be simply:
>
> id = 1;
> while (1) {
> ...
> if (id++ == RT_TABLE_MAX)
> break;
> }
>
> Or even:
>
> id = 0;
> while (++id) {
> ...
> }
>
> .
>
[PATCH v2] ipv4: fib_rules: Fix possible infinite loop in fib_empty_table
gcc warn this:
net/ipv4/fib_rules.c:203 fib_empty_table() warn:
always true condition '(id <= 4294967295) => (0-u32max <= u32max)'
'id' is u32, which always not greater than RT_TABLE_MAX
(0x), So add a check to break while wrap around.
Signed-off-by: YueHaibing
---
v2: clean up exit conditions
---
net/ipv4/fib_rules.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
index f8eb78d..cfec3af 100644
--- a/net/ipv4/fib_rules.c
+++ b/net/ipv4/fib_rules.c
@@ -198,11 +198,15 @@ static int fib4_rule_match(struct fib_rule *rule, struct
flowi *fl, int flags)
static struct fib_table *fib_empty_table(struct net *net)
{
- u32 id;
+ u32 id = 1;
- for (id = 1; id <= RT_TABLE_MAX; id++)
+ while (1) {
if (!fib_get_table(net, id))
return fib_new_table(net, id);
+
+ if (id++ == RT_TABLE_MAX)
+ break;
+ }
return NULL;
}
--
2.7.4
RE: [RFC PATCH 1/1] PM / Domains: Add multi PM domains support for attach_dev
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Friday, December 28, 2018 11:37 PM
>
> On Thu, 27 Dec 2018 at 18:14, Aisheng Dong
> wrote:
> >
> > Currently attach_dev() in power domain infrastructure still does not
> > support multi domains case as the struct device *dev passed down from
> > genpd_dev_pm_attach_by_id() is a virtual PD device, it does not help
> > for parsing the real device information from device tree, e.g.
> > Device/Power IDs, Clocks and it's unware of which real power domain
> > the device should attach.
>
> Thanks for working on this!
>
> I would appreciate if the changelog could clarify the problem a bit.
> Perhaps something along the lines of the below.
>
Sounds good to me.
I will add them in commit message.
Thanks for the suggestion.
> "A genpd provider's ->attach_dev() callback may be invoked with a so called
> virtual device, which is created by genpd, at the point when a device is being
> attached to one of its corresponding multiple PM domains.
>
> In these cases, the genpd provider fails to look up any resource, by a
> clk_get() for example, for the virtual device in question. This is because,
> the
> virtual device that was created by genpd, does not have the virt_dev->of_node
> assigned."
>
> >
> > Extend the framework a bit to store the multi PM domains information
> > in per-device struct generic_pm_domain_data, then power domain driver
> > could retrieve it for necessary operations during attach_dev().
> >
> > Two new APIs genpd_is_mpd_device() and dev_gpd_mpd_data() are also
> > introduced to ease the driver operation.
> >
> > Cc: "Rafael J. Wysocki"
> > Cc: Kevin Hilman
> > Cc: Ulf Hansson
> > Cc: Greg Kroah-Hartman
> > Signed-off-by: Dong Aisheng
> > ---
> > This patch is a follow-up work of the earlier discussion with Ulf
> > Hansson about the multi PM domains support for the attach_dev() function
> [1].
> > After a bit more thinking, this is a less intrusive implementation
> > with the mininum impact on the exist function definitions and calling
> follows.
> > One known little drawback is that we have to use the device driver
> > private data (device.drvdata) to pass down the multi domains
> > information in a earlier time. However, as multi PD devices are
> > created by domain framework, this seems to be safe to use it in domain
> > core code as device driver is not likely going to use it.
> > Anyway, if any better ideas, please let me know.
> >
> > With the two new APIs, the using can be simply as:
> > static int xxx_attach_dev(struct generic_pm_domain *domain,
> > struct device *dev) {
> > ...
> > if (genpd_is_mpd_device(dev)) {
> > mpd_data = dev_gpd_mpd_data(dev);
> > np = mpd_data->parent->of_node;
> > idx = mpd_data->index;
> > //dts parsing
> > ...
> > }
> > ...
>
> I think we can make this a lot less complicated. Just assign
> virt_dev->of_node =
> of_node_get(dev->of_node), somewhere in
> genpd_dev_pm_attach_by_id() and before calling __genpd_dev_pm_attach().
>
> Doing that, would mean the genpd provider's ->attach_dev() callback, don't
> have to distinguish between virtual and non-virtual devices.
> Instead they should be able to look up resources in the same way as they did
> before.
>
Yes, that seems like a smart way.
But there's still a remain problem that how about the domain index information
needed for attach_dev()?
Regards
Dong Aisheng
> Kind regards
> Uffe
>
> > }
> >
> > ---
> > drivers/base/power/domain.c | 31 +++
> > include/linux/pm_domain.h | 23 +++
> > 2 files changed, 54 insertions(+)
> >
> > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> > index 7f38a92..1aa0918 100644
> > --- a/drivers/base/power/domain.c
> > +++ b/drivers/base/power/domain.c
> > @@ -1343,6 +1343,9 @@ static struct generic_pm_domain_data
> *genpd_alloc_dev_data(struct device *dev,
> > gpd_data->td.effective_constraint_ns =
> PM_QOS_RESUME_LATENCY_NO_CONSTRAINT_NS;
> > gpd_data->nb.notifier_call = genpd_dev_pm_qos_notifier;
> >
> > + if (genpd_is_mpd_device(dev))
> > + gpd_data->mpd_data = dev_get_drvdata(dev);
> > +
> > spin_lock_irq(>power.lock);
> >
> > if (dev->power.subsys_data->domain_data) { @@ -2179,6 +2182,7
> > @@ EXPORT_SYMBOL_GPL(of_genpd_remove_last);
> >
> > static void genpd_release_dev(struct device *dev) {
> > + kfree(dev->driver_data);
> > kfree(dev);
> > }
> >
> > @@ -2320,6 +2324,20 @@ int genpd_dev_pm_attach(struct device *dev)
> > EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
> >
> > /**
> > + * genpd_is_mpd_device - Check if a device is associated with multi
> > + PM domains
> > + * @dev: Device to check.
> > + */
> > +
> > +bool genpd_is_mpd_device(struct device *dev) {
> > + if (!dev || (dev && !dev->bus))
> > +
Re: KASAN: use-after-free Read in filemap_fault
On Sat, Dec 29, 2018 at 12:51 AM Kirill A. Shutemov
wrote:
>
> On Fri, Dec 28, 2018 at 01:09:38PM -0800, Andrew Morton wrote:
> > On Fri, 28 Dec 2018 12:51:04 -0800 syzbot
> > wrote:
> >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> >
> > uh-oh. Josef, could you please take a look?
> >
> > : page = find_get_page(mapping, offset);
> > : if (likely(page) && !(vmf->flags & FAULT_FLAG_TRIED)) {
> > : /*
> > : * We found the page, so try async readahead before
> > : * waiting for the lock.
> > : */
> > : fpin = do_async_mmap_readahead(vmf, page);
> > : } else if (!page) {
> > : /* No page in the page cache at all */
> > : fpin = do_sync_mmap_readahead(vmf);
> > : count_vm_event(PGMAJFAULT);
> > : count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> >
> > vmf->vma has been freed at this point.
> >
> > : ret = VM_FAULT_MAJOR;
> > : retry_find:
> > : page = pagecache_get_page(mapping, offset,
> > : FGP_CREAT|FGP_FOR_MMAP,
> > : vmf->gfp_mask);
> > : if (!page) {
> > : if (fpin)
> > : goto out_retry;
> > : return vmf_error(-ENOMEM);
> > : }
> > : }
> >
>
> Here's a fixup for "filemap: drop the mmap_sem for all blocking operations".
If you are going to squash this, please add:
Tested-by: syzbot+b437b5a429d680cf2...@syzkaller.appspotmail.com
> do_sync_mmap_readahead() drops mmap_sem now, so by the time of
> dereferencing vmf->vma for count_memcg_event_mm() the VMA can be gone.
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 00a9315f45d4..65c85c47bdb1 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2554,10 +2554,10 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
> fpin = do_async_mmap_readahead(vmf, page);
> } else if (!page) {
> /* No page in the page cache at all */
> - fpin = do_sync_mmap_readahead(vmf);
> count_vm_event(PGMAJFAULT);
> count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> ret = VM_FAULT_MAJOR;
> + fpin = do_sync_mmap_readahead(vmf);
> retry_find:
> page = pagecache_get_page(mapping, offset,
> FGP_CREAT|FGP_FOR_MMAP,
> --
> Kirill A. Shutemov
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/20181228235106.okk3oastsnpxusxs%40kshutemo-mobl1.
> For more options, visit https://groups.google.com/d/optout.
KASAN: slab-out-of-bounds Read in perf_exclude_event
Hello, syzbot found the following crash on: HEAD commit:7566ec393f41 Linux 4.20-rc7 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16c1b21b40 kernel config: https://syzkaller.appspot.com/x/.config?x=861a3573f4e78ba1 dashboard link: https://syzkaller.appspot.com/bug?extid=90e033e65bf7256f2afb compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+90e033e65bf7256f2...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in perf_exclude_event+0x18b/0x1a0 kernel/events/core.c:7895 Read of size 8 at addr 8881b09cff90 by task syz-executor2/30277 CPU: 0 PID: 30277 Comm: syz-executor2 Not tainted 4.20.0-rc7+ #154 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 perf_exclude_event+0x18b/0x1a0 kernel/events/core.c:7895 perf_swevent_hrtimer+0x28f/0x510 kernel/events/core.c:9153 __run_hrtimer kernel/time/hrtimer.c:1398 [inline] __hrtimer_run_queues+0x41c/0x10d0 kernel/time/hrtimer.c:1460 hrtimer_interrupt+0x313/0x780 kernel/time/hrtimer.c:1518 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1034 [inline] smp_apic_timer_interrupt+0x1a1/0x760 arch/x86/kernel/apic/apic.c:1059 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807 Allocated by task 30091: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620 kmalloc include/linux/slab.h:546 [inline] kzalloc include/linux/slab.h:741 [inline] kernfs_iop_get_link+0x6d/0x690 fs/kernfs/symlink.c:136 get_link fs/namei.c:1084 [inline] trailing_symlink+0x779/0x970 fs/namei.c:2263 path_openat+0xb58/0x5150 fs/namei.c:3536 do_filp_open+0x255/0x380 fs/namei.c:3564 do_sys_open+0x568/0x700 fs/open.c:1063 __do_sys_open fs/open.c:1081 [inline] __se_sys_open fs/open.c:1076 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1076 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 30091: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xcf/0x230 mm/slab.c:3817 kfree_link+0x15/0x20 fs/libfs.c:1105 do_delayed_call include/linux/delayed_call.h:28 [inline] put_link fs/namei.c:883 [inline] step_into fs/namei.c:1772 [inline] do_last fs/namei.c:3383 [inline] path_openat+0x1ed3/0x5150 fs/namei.c:3534 do_filp_open+0x255/0x380 fs/namei.c:3564 do_sys_open+0x568/0x700 fs/open.c:1063 __do_sys_open fs/open.c:1081 [inline] __se_sys_open fs/open.c:1076 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1076 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 8881b09ce080 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 3856 bytes to the right of 4096-byte region [8881b09ce080, 8881b09cf080) The buggy address belongs to the page: page:ea0006c27380 count:1 mapcount:0 mapping:8881da800dc0 index:0x0 compound_mapcount: 0 flags: 0x2fffc010200(slab|head) raw: 02fffc010200 ea00070ee188 ea0006ff4d08 8881da800dc0 raw: 8881b09ce080 00010001 page dumped because: kasan: bad access detected Memory state around the buggy address: 8881b09cfe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8881b09cff00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc 8881b09cff80: fc fc fc fc fc fc fc fc fc fc fc f1 f1 f1 f1 00 ^ 8881b09d: f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 8881b09d0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
[PATCH] mm/slub.c: freelist is ensured to be NULL when new_slab() fails
new_slab_objects() will return immediately if freelist is not NULL. if (freelist) return freelist; One more assignment operation could be avoided. Signed-off-by: Peng Wang --- mm/slub.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 36c0befeebd8..cf2ef4ababff 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2463,8 +2463,7 @@ static inline void *new_slab_objects(struct kmem_cache *s, gfp_t flags, stat(s, ALLOC_SLAB); c->page = page; *pc = c; - } else - freelist = NULL; + } return freelist; } -- 2.19.1
Re: [PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
Am 28.12.18 um 16:43 schrieb Alexander Aring: > On Fri, Dec 28, 2018 at 05:57:53AM +0100, Andreas Färber wrote: >> Am 24.12.18 um 16:32 schrieb Alexander Aring: >>> On Tue, Dec 18, 2018 at 02:50:58PM +0100, Xue Liu wrote: On Mon, 17 Dec 2018 at 15:19, Andreas Färber wrote: > Am 17.12.18 um 09:50 schrieb Xue Liu: >> I have a question about the architecture of your module. AFAIK LoRaWAN >> is already the MAC Layer above the LoRa technology. Why do you want to >> make a new layer called "maclorawan" ? > > I had asked Jian-Hong to separate between his soft-MAC implementation > and the common bits needed to drive hard-MAC implementations found on > several of the hardware modules made available to me. > As a reference Linux 802.11 uses cfg80211 to talk with hard-MAC devices. We may also use the name “cfglora” for hard-MAC implementation. >>> >>> There exists also a cfg802154. :-) >>> >>> Note that cfg80211 is also for providing a backwardscompatibility to the >>> wireless ioctl() interface. >>> >>> In theory it's simple: >>> >>> netlink API -> SoftMAC (macFOOBAR layer) -> cfgFOOBAR implementation -> >>> driver layer >>> \-> HardMAC (driver layer) -> cfgFOOBAR implementation >> >> So how does cfgFOOBAR relate to nlFOOBAR now? Given that we were told to >> use netlink and pointed to some nl802whatever, I am confused about two >> people now calling for cfg. We have an nllora stubbed in linux-lora.git, >> and I was expecting to see an nllorawan¹ either in this series or on > > Why there is a different between two lora technologies? This sounds you > driving into two lora subsystems without one userspace api to access them, > this getting worse. This had just been explained to Jiri: LoRa PHY vs. LoRaWAN MAC. Similar splits exist for other technologies; and how the LoRaWAN soft-MAC can reuse underlying LoRa facilities is the very subject of this sub-thread! It entirely depends on what the user wants to do - connect to a LoRaWAN network as client, forward LoRaWAN packets as a gateway, communicate peer-to-peer, implement alternative MACs in userspace, ... So if a user is working on LoRaWAN MAC layer I expect him to deal with PF_LORAWAN and nllorawan and not need direct access to nllora, as that would be an implementation detail specific to the soft-MAC; a hard-MAC should not need to implement nllora, as it may not have that control. >> top. If you're suggesting to rename them technology-neutral, then please > > I am sorry, I actually meant that... People tell me that I can't explain > things all the time. > >> say so clearly - otherwise it sounds to me like you didn't actually look >> at the staged code yet or didn't read our previous discussions and lead >> our contributors to reinvent things we already have... > > As example for 802.15.4: > > nl802154 (which is one netlink interface for doesn't matter what > kind 802.15.4 device is behind) -> callback structure of cfg802154 which > goes to a somehow 802.15.4 device as SoftMAC layer or HardMAC driver. Okay, I took a shortcut there for LoRa and assume we always have a LoRa netdev (i.e., no theoretical SDR netdev), so that I could postpone figuring out how to register extra per-netdev cfg structs for quicker PoC of the netlink interface. :) My get_freq callback will need to be moved out from struct lora_dev_priv (lora/netdev.h) into its own struct. >> We really need to complete the layers from the ground up before we get >> lost in more nice-to-have upper layers: For LoRaWAN that means we need >> to have TX and RX working for LoRa _and_ FSK. sx1276 still has lots of >> hardcoded stuff from my own testing that needs to hook into nllora, and >> FSK exists only as ETH_P_FSK constant so far, with no concept for >> switching modes yet (which as mentioned in my presentation¹ needs to go >> via sleep mode, losing most register settings) nor any netlink support. >> Not all drivers need to be at the same implementation level, of course, >> but we need at least one that's far enough to validate such patches. > > Your register behaviour sounds for me like a feature for regmap. Or > either a feature to handle in your subsystem. We don't have regmap caching enabled. sx1276 has no paging implemented, as it's slightly more complicated than sx1301 (and the "youngest" of 3). I assume instead of just writing from netlink/cfg callbacks to regmap we'll need to also save the values in the driver for writing them back after a mode switch or suspend. However it's also a question of who initiates the mode switch and how, presumably via netlink. >> And seeing that I just found a major bug in sx1276 driver's TX path, >> apparently no one apart from me is testing that driver - sx128x and >> sx1301 were not yet complete enough to transmit, and due to the open >> socket address/protocol discussions none can receive yet, so as Jiri >> hinted, this LoRaWAN soft-MAC patch series can't have been >> runtime-tested against
Re: [PATCH 00/20] drop useless LIST_HEAD
On Fri, 28 Dec 2018, Darrick J. Wong wrote: > On Thu, Dec 27, 2018 at 04:40:55PM +0300, Dan Carpenter wrote: > > On Tue, Dec 25, 2018 at 11:12:20PM +0100, Tom Psyborg wrote: > > > there was discussion about this just some days ago. CC 4-5 lists is > > > more than enough > > > > > > > I don't know who you were discussing this with... > > > > You should CC the 0th patch to all the mailinglists. That much is a > > clear rule. > > > > For the rest, Julia's position is the more conservative one. I was in > > a conversation in RL and they were like, "CC everyone for all the > > patches". It depends on the context, of course. If the patches are > > dependent on each other then you *have* to CC everyone for everything. > > Agreed. Ms. Lawall, sending "Cover letter + all relevant XFS patches" > (as you did) was exactly the right thing for us xfs types. :) > > For that matter, we prefer to receive through linux-xfs more patches > than necessary (one can send the entire series if one is unsure) than to > go wanting for more context. Thanks for the confirmation. I was planning to ignore the 4-5 advice, because there is no way in this case to make a meaningful 4-5 list suggestion - it's either all or nothing. But 20 patches at once is perhaps a lot as well. In this case, I just wanted to get rid of the whole issue at once. julia
[PATCH] x86/mm/mem_encrypt_identity : fix error useage to sizeof
Fix error usage to sizeof. It should not use sizeof to pointer.
Signed-off-by: Peng Hao
---
arch/x86/mm/mem_encrypt_identity.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/mem_encrypt_identity.c
b/arch/x86/mm/mem_encrypt_identity.c
index a19ef1a..4aa9b14 100644
--- a/arch/x86/mm/mem_encrypt_identity.c
+++ b/arch/x86/mm/mem_encrypt_identity.c
@@ -158,8 +158,8 @@ static void __init sme_populate_pgd(struct
sme_populate_pgd_data *ppd)
pmd = pmd_offset(pud, ppd->vaddr);
if (pmd_none(*pmd)) {
pte = ppd->pgtable_area;
- memset(pte, 0, sizeof(pte) * PTRS_PER_PTE);
- ppd->pgtable_area += sizeof(pte) * PTRS_PER_PTE;
+ memset(pte, 0, sizeof(*pte) * PTRS_PER_PTE);
+ ppd->pgtable_area += sizeof(*pte) * PTRS_PER_PTE;
set_pmd(pmd, __pmd(PMD_FLAGS | __pa(pte)));
}
--
1.8.3.1
[PATCH] power_suuupy: change brace's place
---
drivers/power/supply/power_supply_sysfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index 5204f115970f..be1577e96c59 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -75,7 +75,8 @@ static const char * const power_supply_scope_text[] = {
static ssize_t power_supply_show_property(struct device *dev,
struct device_attribute *attr,
- char *buf) {
+ char *buf)
+{
ssize_t ret = 0;
struct power_supply *psy = dev_get_drvdata(dev);
const ptrdiff_t off = attr - power_supply_attrs;
--
2.19.1
Re: [GIT PULL] libnvdimm for 4.21
Hmm. This pull request doesn't seem to have gotten an automatic pr-tracker reply, even though I pulled it, and even though it was cc'd to lkml. Konstantin, any idea why the automation didn't trigger? I'm not seeing anything all that odd about it. [ looks around ] Oh, I notice that I can't seem to find this message on lore.kernel.org either, despite seeing that lkml cc when I look at my copy of the email. Does lkml hate Dan? Headers say To: "torva...@linux-foundation.org" CC: "linux-kernel@vger.kernel.org" , "linux-nvd...@lists.01.org" ... Date: Fri, 28 Dec 2018 05:04:27 + Message-ID: <4880b31d0d32c38a675048be903814a062907125.ca...@intel.com> but when I try to look it up on lore.kernel.org, I get: Message-ID <4880b31d0d32c38a675048be903814a062907125.ca...@intel.com> not found Weird. Linus On Thu, Dec 27, 2018 at 9:04 PM Williams, Dan J wrote: > > Hi Linus, please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/libnvdimm-for-4.21 > > ...to receive the libnvdimm update for 4.21. [...]
Re: [PATCH 1/1] net-next/hinic:add shutdown callback
From: Xue Chaojing
Date: Fri, 28 Dec 2018 00:20:40 +
> @@ -1106,6 +1106,13 @@ static void hinic_remove(struct pci_dev *pdev)
> dev_info(>dev, "HiNIC driver - removed\n");
> }
>
> +static void hinic_shutdown(struct pci_dev *pdev)
> +{
> + pci_disable_device(pdev);
> +
> + dev_info(>dev, "HiNIC driver - shutdown\n");
> +}
I do not think these messages are appropriate. I didn't catch
them before, but I'm not going to let new ones get added.
Re: [GIT PULL] hwmon updates for v4.21
The pull request you sent on Sun, 23 Dec 2018 14:12:29 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git > hwmon-for-v4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8754040378e4ff70b3bb96b1dabac62da5dfb870 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] VFIO updates for v4.21-rc1
The pull request you sent on Fri, 21 Dec 2018 09:31:30 -0700: > git://github.com/awilliam/linux-vfio.git tags/vfio-v4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1984f65c2fbc0d2b557d6e89ece9b39267e215c6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Staging/IIO driver patches for 4.21-rc1
The pull request you sent on Fri, 28 Dec 2018 16:35:31 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > tags/staging-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/02061181d3a9ccfe15ef6bc15fa56283acc47620 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] GPIO bulk changes for the v4.21 kernel
The pull request you sent on Thu, 27 Dec 2018 10:23:35 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git > tags/gpio-v4.21-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/24dc83635ffe3c93d8122099a83ee228c9b7e4f7 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] USB/PHY driver patches for 4.21-rc1
The pull request you sent on Fri, 28 Dec 2018 16:34:42 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c0ea81b4d37837409d0dfd2036098a7babb312ed Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] TTY/Serial patches for 4.21-rc1
The pull request you sent on Fri, 28 Dec 2018 16:35:06 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/117eda8f71ff545cfdec8fe8073adbd173a1ceff Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] hsi changes for hsi-4.21
The pull request you sent on Fri, 28 Dec 2018 14:10:03 +0100: > ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git > tags/hsi-for-4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4d6ad6fba6b7af06143c67964f4095c74c9ce87c Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] kselftest update for Linux 4.21-rc1
The pull request you sent on Fri, 21 Dec 2018 09:45:50 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest > tags/linux-kselftest-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/903b77c631673eeec9e9114e9524171cdf9a2646 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] DeviceTree updates for v4.21
The pull request you sent on Thu, 27 Dec 2018 13:44:21 -0600: > git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git > devicetree-for-4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/030672aea826adf3dee9100ee8ac303b62c8fe7f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Driver core patches for 4.21-rc1
The pull request you sent on Fri, 28 Dec 2018 16:36:09 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > tags/driver-core-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b07039b79c9ea64c1eacda1e01d645082e4a0d5d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Char/Misc driver patches for 4.21-rc1
The pull request you sent on Fri, 28 Dec 2018 16:36:53 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > tags/char-misc-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/457fa3469a65a524be04412f5cd497fa3b11c9fd Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] drm next leftovers for rc1
The pull request you sent on Thu, 27 Dec 2018 10:09:49 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-12-27 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7e59fad9c9d1aeacdc96dfffd35f9e12ddc34dbf Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] power-supply changes for 4.21
The pull request you sent on Fri, 28 Dec 2018 14:08:52 +0100: > ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git > tags/for-v4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/579a70035949b771a63a686db8becdd9b197d986 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v2] net: arcnet: Fix a possible concurrency use-after-free bug in arcnet_reply_tasklet()
From: Jia-Ju Bai Date: Thu, 27 Dec 2018 10:01:42 +0800 > @@ -401,6 +401,7 @@ static void arcnet_reply_tasklet(unsigned long data) > struct sock_exterr_skb *serr; > struct sock *sk; > int ret; > + unsigned long flags; > > local_irq_disable(); > skb = lp->outgoing.skb; > @@ -426,10 +427,14 @@ static void arcnet_reply_tasklet(unsigned long data) > serr->ee.ee_data = skb_shinfo(skb)->tskey; > serr->ee.ee_info = lp->reply_status; > > + spin_lock_irqsave(>lock, flags); > + > /* finally erasing outgoing skb */ > dev_kfree_skb(lp->outgoing.skb); > lp->outgoing.skb = NULL; > > + spin_unlock_irqrestore(>lock, flags); > + > ackskb->dev = lp->dev; > > ret = sock_queue_err_skb(sk, ackskb); This is not the correct fix. You need to instead replace the existing local_irq_*() calls in the function with the spinlock stuff.
Re: [PATCH] isdn: hisax: hfc_pci: Fix a possible concurrency use-after-free bug in HFCPCI_l1hw()
From: Jia-Ju Bai Date: Wed, 26 Dec 2018 22:09:34 +0800 > In drivers/isdn/hisax/hfc_pci.c, the functions hfcpci_interrupt() and > HFCPCI_l1hw() may be concurrently executed. > > HFCPCI_l1hw() > line 1173: if (!cs->tx_skb) > > hfcpci_interrupt() > line 942: spin_lock_irqsave(); > line 1066: dev_kfree_skb_irq(cs->tx_skb); > > Thus, a possible concurrency use-after-free bug may occur > in HFCPCI_l1hw(). > > To fix these bugs, the calls to spin_lock_irqsave() and > spin_unlock_irqrestore() are added in HFCPCI_l1hw(), to protect the > access to cs->tx_skb. > > Signed-off-by: Jia-Ju Bai Applied.
Re: [PATCH 00/20] drop useless LIST_HEAD
On Thu, Dec 27, 2018 at 04:40:55PM +0300, Dan Carpenter wrote: > On Tue, Dec 25, 2018 at 11:12:20PM +0100, Tom Psyborg wrote: > > there was discussion about this just some days ago. CC 4-5 lists is > > more than enough > > > > I don't know who you were discussing this with... > > You should CC the 0th patch to all the mailinglists. That much is a > clear rule. > > For the rest, Julia's position is the more conservative one. I was in > a conversation in RL and they were like, "CC everyone for all the > patches". It depends on the context, of course. If the patches are > dependent on each other then you *have* to CC everyone for everything. Agreed. Ms. Lawall, sending "Cover letter + all relevant XFS patches" (as you did) was exactly the right thing for us xfs types. :) For that matter, we prefer to receive through linux-xfs more patches than necessary (one can send the entire series if one is unsure) than to go wanting for more context. --D > If we really have other clear rules, then it should be encoded into > get_maintainer.pl so that it's automatic. > > My other question is why do the linux-arm-ker...@lists.infradead.org > people feel like they need to be CC'd about every driver??? I always > remove them from the CC list unless it's an arch/arm issue. > > regards, > dan carpenter > > PS: Please, no more top posting. >
Re: [PATCH net] ethtool: check the return value of get_regs_len
From: Yunsheng Lin Date: Wed, 26 Dec 2018 19:51:46 +0800 > The return type for get_regs_len in struct ethtool_ops is int, > the hns3 driver may return error when failing to get the regs > len by sending cmd to firmware. > > Signed-off-by: Yunsheng Lin > --- > Note: There is not Fixes tags for this becuase the ops is added > before the git is used. Applied, thanks.
Re: [PATCH] ipv4: fib_rules: Fix possible infinite loop in fib_empty_table
From: YueHaibing
Date: Wed, 26 Dec 2018 16:34:20 +0800
> diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
> index f8eb78d..1567e12 100644
> --- a/net/ipv4/fib_rules.c
> +++ b/net/ipv4/fib_rules.c
> @@ -200,9 +200,13 @@ static struct fib_table *fib_empty_table(struct net *net)
> {
> u32 id;
>
> - for (id = 1; id <= RT_TABLE_MAX; id++)
> + for (id = 1; id <= RT_TABLE_MAX; id++) {
> if (!fib_get_table(net, id))
> return fib_new_table(net, id);
> +
> + if (id == RT_TABLE_MAX)
> + break;
> + }
> return NULL;
> }
The loop now has two exit conditions, one of which (by your analysis
is completely impossible).
Please clean this up into a loop with better structure and no
impossible tests. One approach could be simply:
id = 1;
while (1) {
...
if (id++ == RT_TABLE_MAX)
break;
}
Or even:
id = 0;
while (++id) {
...
}
Re: [PATCH v3] soc/fsl/qe: fix err handling of ucc_of_parse_tdm
From: Peng Hao
Date: Wed, 26 Dec 2018 16:26:29 +0800
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 839fa77..8ce4921f 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -1057,6 +1057,27 @@ static const struct net_device_ops uhdlc_ops = {
> .ndo_tx_timeout = uhdlc_tx_timeout,
> };
>
> +static int ucc_get_resource_by_nodename(char *name, struct resource *res)
> +{
...
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + return 0;
This assignment to 'res' doesn't do what you think it does. The caller never
sees the value you compute.
Re: [GIT PULL] security: general updates for v4.21
On Fri, 28 Dec 2018, Linus Torvalds wrote: > On Fri, Dec 28, 2018 at 7:11 PM James Morris wrote: > > > > I do this every development cycle, after requests from security subsystem > > maintainers to sync to -rc kernels. > > Why? > > A merge should have a *reason*. Yep, I understand what you mean. I can't find the discussion from several years ago, but developers asked to be able to work with more current kernels, and I recall you saying that if you want to do this, merge to a specific -rc tag at least. I'm not personally fussed either way, and if anyone cc'd has an opinion, please comment. Otherwise, I'll go back to merging to Linus only as necessary. -- James Morris
[PATCH 2/2] arm/plat-pxa/ssp : unneeded to free devm_ allocated data
devm_ allocated data will be automatically freed. The free of devm_ allocated data is invalid. Signed-off-by: Peng Hao --- arch/arm/plat-pxa/ssp.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/plat-pxa/ssp.c b/arch/arm/plat-pxa/ssp.c index ed36dca..f519199 100644 --- a/arch/arm/plat-pxa/ssp.c +++ b/arch/arm/plat-pxa/ssp.c @@ -190,8 +190,6 @@ static int pxa_ssp_remove(struct platform_device *pdev) if (ssp == NULL) return -ENODEV; - iounmap(ssp->mmio_base); - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); release_mem_region(res->start, resource_size(res)); @@ -201,7 +199,6 @@ static int pxa_ssp_remove(struct platform_device *pdev) list_del(>node); mutex_unlock(_lock); - kfree(ssp); return 0; } -- 1.8.3.1
Re: [GIT PULL] security: general updates for v4.21
On Fri, Dec 28, 2018 at 7:11 PM James Morris wrote: > > I do this every development cycle, after requests from security subsystem > maintainers to sync to -rc kernels. Why? A merge should have a *reason*. Linus
[PATCH 1/2] arm/common/dmabounce : NULL check before dma_pool_destroy
NULL check before dma_pool_destroy is unnecessary because there is a NULL check in dma_pool_destroy. Signed-off-by: Peng Hao --- arch/arm/common/dmabounce.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c index 9a92de6..dcdd80c 100644 --- a/arch/arm/common/dmabounce.c +++ b/arch/arm/common/dmabounce.c @@ -569,10 +569,8 @@ void dmabounce_unregister_dev(struct device *dev) BUG(); } - if (device_info->small.pool) - dma_pool_destroy(device_info->small.pool); - if (device_info->large.pool) - dma_pool_destroy(device_info->large.pool); + dma_pool_destroy(device_info->small.pool); + dma_pool_destroy(device_info->large.pool); #ifdef STATS if (device_info->attr_res == 0) -- 1.8.3.1
Re: [GIT PULL resend] hwmon updates for v4.21
On Fri, Dec 28, 2018 at 6:55 AM Guenter Roeck wrote: > > [ First sent last Sunday. Resending now because I don't know if I will have > internet access in the next few days. I don't know if it got lost, if it > was rejected, or what else may have happened. If it is still in the queue, > my apologies for the noise. If it was rejected, I would appreciate > feedback. It was still just in my queue. It's about to be pulled next. Linus
Re: [PATCH 1/2] pci: altera: Add StratixXX PCIe support
Run "git log --oneline drivers/pci/controller" and make your subject line
match in style, phrasing, and capitalization.
On Thu, Dec 27, 2018 at 01:09:45AM +0800, Ley Foon Tan wrote:
> Add PCIe rootport support for StratixXX device.
s/rootport/Root Port/
I don't know what the correct styling of "StratixXX" is. You also have
"Stratix xx" below. Both (and the subject line) should probably match?
> Main differences:
> - HIP interface
> - TLP programming flow
It'd be nice to elaborate on these differences a little bit.
> Signed-off-by: Ley Foon Tan
> ---
> drivers/pci/controller/Kconfig |2 +-
> drivers/pci/controller/pcie-altera.c | 228
> +++---
> 2 files changed, 209 insertions(+), 21 deletions(-)
> mode change 100644 => 100755 drivers/pci/controller/Kconfig
>
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> old mode 100644
> new mode 100755
> index 6671946..6012f30
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -175,7 +175,7 @@ config PCIE_IPROC_MSI
>
> config PCIE_ALTERA
> bool "Altera PCIe controller"
> - depends on ARM || NIOS2 || COMPILE_TEST
> + depends on ARM || NIOS2 || ARM64 || COMPILE_TEST
> help
> Say Y here if you want to enable PCIe controller support on Altera
> FPGA.
> diff --git a/drivers/pci/controller/pcie-altera.c
> b/drivers/pci/controller/pcie-altera.c
> index 7d05e51..b9d6eb2 100644
> --- a/drivers/pci/controller/pcie-altera.c
> +++ b/drivers/pci/controller/pcie-altera.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -37,7 +38,12 @@
> #define RP_LTSSM_MASK0x1f
> #define LTSSM_L0 0xf
>
> -#define PCIE_CAP_OFFSET 0x80
> +#define SXX_RP_TX_CNTRL 0x2004
> +#define SXX_RP_RXCPL_REG 0x2008
> +#define SXX_RP_RXCPL_STATUS 0x200C
> +#define SXX_RP_CFG_ADDR(pcie, reg) \
> + ((pcie->hip_base) + (reg) + (1 << 20))
> +
> /* TLP configuration type 0 and 1 */
> #define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0 */
> #define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0 */
> @@ -49,18 +55,19 @@
> #define RP_DEVFN 0
> #define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
> #define TLP_CFGRD_DW0(pcie, bus) \
> -bus == pcie->root_bus_nr) ? TLP_FMTTYPE_CFGRD0
> \
> - : TLP_FMTTYPE_CFGRD1) << 24) | \
> +bus == pcie->root_bus_nr) ? pcie->pcie_data->cfgrd0 \
> + : pcie->pcie_data->cfgrd1) << 24) | \
> TLP_PAYLOAD_SIZE)
> #define TLP_CFGWR_DW0(pcie, bus) \
> -bus == pcie->root_bus_nr) ? TLP_FMTTYPE_CFGWR0
> \
> - : TLP_FMTTYPE_CFGWR1) << 24) | \
> +bus == pcie->root_bus_nr) ? pcie->pcie_data->cfgwr0 \
> + : pcie->pcie_data->cfgwr1) << 24) | \
> TLP_PAYLOAD_SIZE)
> #define TLP_CFG_DW1(pcie, tag, be) \
> (((TLP_REQ_ID(pcie->root_bus_nr, RP_DEVFN)) << 16) | (tag << 8) | (be))
> #define TLP_CFG_DW2(bus, devfn, offset) \
> (((bus) << 24) | ((devfn) << 16) | (offset))
> #define TLP_COMP_STATUS(s) (((s) >> 13) & 7)
> +#define TLP_BYTE_COUNT(s)(((s) >> 0) & 0xfff)
> #define TLP_HDR_SIZE 3
> #define TLP_LOOP 500
>
> @@ -72,11 +79,30 @@
> struct altera_pcie {
> struct platform_device *pdev;
> void __iomem*cra_base; /* DT Cra */
> + void __iomem*hip_base;
IIRC, the "DT Cra" comment was a hint about what DT property contains
this data. It'd be good to use the comment consistently (either
always or never).
> int irq;
> u8 root_bus_nr;
> struct irq_domain *irq_domain;
> struct resource bus_range;
> struct list_headresources;
> + const struct altera_pcie_data *pcie_data;
> +};
> +
> +struct altera_pcie_data {
> + int (*tlp_read_pkt)(struct altera_pcie *pcie, u32 *value);
> + void (*tlp_write_pkt)(struct altera_pcie *pcie, u32 *headers,
> + u32 data, bool align);
> + bool (*get_link_status)(struct altera_pcie *pcie);
> + int (*rp_read_cfg)(struct altera_pcie *pcie, int where,
> + int size, u32 *value);
> + int (*rp_write_cfg)(struct altera_pcie *pcie, u8 bus, int where,
> +int size, u32 value);
> + bool sxx_flag; /* Stratix xx */
> + u32 cap_offset; /* Capabilities register offset */
I guess this is the *PCIe*
RE: [PATCH v4 10/10] KVM/x86/lbr: lazy save the guest lbr stack II
On Friday, December 28, 2018 4:53 AM, Andi Kleen wrote: > Actually forgot one case. > > In Arch Perfmon v4 the LBR freezing is also controlled through a > GLOBAL_CTRL bit. > I didn't see any code handling that bit? That GLOBAL_STATUS.LBR_FRZ bit hasn't been supported yet. I'll add that, thanks. Best, Wei
Re: [V9fs-developer] [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation
Theodore Y. Ts'o wrote on Fri, Dec 28, 2018: > On Sat, Dec 29, 2018 at 03:37:21AM +0100, Dominique Martinet wrote: > > > Are there going to be cases where a process or a thread will sometimes > > > want the 64-bit interface, and sometimes want the 32-bit interface? > > > Or is it always going to be one or the other? I wonder if we could > > > simply add a new flag to the process personality(2) flags. > > > > That would likely work for qemu user, but the qemu system+9p case is > > going to be more painful.. > > More precisely, the 9p protocol does not plan for anything other than > > 64bit offset so if the vfs needs to hand out a 32bit offset we'll need > > to make a correspondance table between the 32bit offsets we hand off and > > the 64bit ones to use; unless some flag can be passed at lopen to tell > > the server to always hand out 32bit offsets for this directory... And if > > we do that then 9p servers will need a way to use both APIs in parallel > > for both types of directories. > > How about if we add a fcntl(2) mediated flag, which is tied to a > struct file? Would that be more or less painful for 9p and qemu > system+9p? Hmm. 9P2000.L doesn't have anything akin to fcntl either, the only two obvious places where we could pass a flag is lopen (which already handles a bunch of linux-specific flags, e.g. passing O_LARGEFILE O_NOATIME etc will just forward these through for qemu/diod at least), or adding a new parameter to the 9p readdir. The former would let us get away without modifying the protocol as servers will just ignore flags they don't handle on implementations I checked, so it'd definitely be the least effort choice from what I can tell. On the other hand a fcntl would solve the server-side problem, it'd allow the server to request appropriately-sized offsets per fd, so it's a good start; we "just" need to figure how to translate that on the wire. -- Dominique Martinet | Asmadeus
Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation
On Sat, Dec 29, 2018 at 03:37:21AM +0100, Dominique Martinet wrote: > > Are there going to be cases where a process or a thread will sometimes > > want the 64-bit interface, and sometimes want the 32-bit interface? > > Or is it always going to be one or the other? I wonder if we could > > simply add a new flag to the process personality(2) flags. > > That would likely work for qemu user, but the qemu system+9p case is > going to be more painful.. > More precisely, the 9p protocol does not plan for anything other than > 64bit offset so if the vfs needs to hand out a 32bit offset we'll need > to make a correspondance table between the 32bit offsets we hand off and > the 64bit ones to use; unless some flag can be passed at lopen to tell > the server to always hand out 32bit offsets for this directory... And if > we do that then 9p servers will need a way to use both APIs in parallel > for both types of directories. How about if we add a fcntl(2) mediated flag, which is tied to a struct file? Would that be more or less painful for 9p and qemu system+9p? - Ted
Re: Re: [PATCH] bitmap: Add bitmap_valloc(), bitmap_vzalloc() and bitmap_vfree()
On Date: Fri, 28 Dec 2018 15:41:37 -0800 Andrew Morton wrote: > From: "Andrew Morton" > Sent Time: 2018-12-29 07:41:37 (Saturday) > To: "Peng Wang" > Cc: andriy.shevche...@linux.intel.com, li...@rasmusvillemoes.dk, > yno...@caviumnetworks.com, a...@arndb.de, cour...@google.com, osan...@fb.com, > linux-kernel@vger.kernel.org > Subject: Re: [PATCH] bitmap: Add bitmap_valloc(), bitmap_vzalloc() and > bitmap_vfree() > > On Fri, 28 Dec 2018 00:18:29 +0800 Peng Wang wrote: > > > Introduce bitmap alloc/free helpers when contiguous > > memory is not necessary. > > That's a large bitmap you have there. What code needs this? Hi Andrew, Not only for large bitmap. This can also benefit from high memory pressure with no requirement for physical continuousness. While these two casees are rather rare. And I only find one place in mm/swapfile.c. 3224 /* frontswap enabled? set up bit-per-page map for frontswap */ 3225 if (IS_ENABLED(CONFIG_FRONTSWAP)) 3226 frontswap_map = kvcalloc(BITS_TO_LONGS(maxpages), 3227 sizeof(long), 3228 GFP_KERNEL); I am not sure whether these helper functions can gain as much benefits as the efforts to introduce them. Cheers, Peng
Re: [GIT PULL] security: general updates for v4.21
On Fri, Dec 28, 2018 at 8:09 PM James Morris wrote: > > Yep, I understand what you mean. I can't find the discussion from several > years ago, but developers asked to be able to work with more current > kernels, and I recall you saying that if you want to do this, merge to a > specific -rc tag at least. If people really want it, maybe the merge can state that explicit thing, as it is I'm trying to push back on empty merges that don't explain why they even exist. Linus
Re: [PATCH v5 1/2] lib: add crc64 calculation routines
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/29/18 10:58 上午, NeilBrown wrote:
> On Thu, Jul 26 2018, Andrew Morton wrote:
>
>> On Thu, 26 Jul 2018 13:33:51 +0800 Coly Li
>> wrote:
>>
>>> This patch adds the re-write crc64 calculation routines for
>>> Linux kernel. The CRC64 polynomial arithmetic follows ECMA-182
>>> specification, inspired by CRC paper of Dr. Ross N. Williams
>>> (see http://www.ross.net/crc/download/crc_v3.txt) and other
>>> public domain implementations.
>
> Hi Coly and Andrew,
>
> This patch breaks compilation if linux headers files are not
> installed (reported at
> https://github.com/gnubee-git/GnuBee_Docs/issues/75). Following
> fixes it.
>
> Thanks, NeilBrown
>
Hi Neil,
Thanks for the fix. I add by Acked-by.
Coly Li
> From: NeilBrown Subject: [PATCH] lib: don't
> depend on linux headers being installed.
>
> gen_crc64table requires linux include files to be installed in
> /usr/include/linux. This is a new requrement so hosts that could
> previously build the kernel, now cannot.
>
> gen_crc64table makes this requirement by including ,
> but nothing from that header is actaully used.
>
> So remove the #include, so that the linux headers no longer need to
> be installed.
>
> Fixes: feba04fd2cf8 ("lib: add crc64 calculation routines")
> Signed-off-by: NeilBrown
Acked-by: Coly Li
> --- lib/gen_crc64table.c | 2 -- 1 file changed, 2 deletions(-)
>
> diff --git a/lib/gen_crc64table.c b/lib/gen_crc64table.c index
> 9011926e4162..094b43aef8db 100644 --- a/lib/gen_crc64table.c +++
> b/lib/gen_crc64table.c @@ -16,8 +16,6 @@ #include
> #include
>
> -#include - #define CRC64_ECMA182_POLY
> 0x42F0E1EBA9EA3693ULL
>
> static uint64_t crc64_table[256] = {0};
>
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
iQIzBAEBCAAdFiEE6j5FL/T5SGCN6PrQxzkHk2t9+PwFAlwm8JsACgkQxzkHk2t9
+PxELA//U8FohU56Xty9Yfe/5IX0WXHzpLk8efz34xNodo1bavy9yIlpzG8l9cX5
c2vaM4hYvc2rrYokgkxHcANSpFkRzD9TjkwNbij7wd37lEJYzPWr0Qk1Ttuojs7b
iJYLis0pbu6WTeUpM4NwdkKzylqWXg0dRrf3tNpF5ttN+LZOSEzbIiP8P2rnQUmD
a9WCM6Ka/E9dP5H2CIvR6gAJL/BwsVyFgd6PiYy8ElMVYBpIu2uG34eO0tx6ebSE
TPxWrSXY92jWCggJUBNr5zDXyBQADBQfy0YIv36zsplcolF/4mN4LWF2WCC4jp0c
XLBrvSslzombjxq3h+zE4GNXsDNiKtaNQy1N30b1+N3ilXa4uav1wVvaBQBMwf4I
QQDM8ZZ2alS5zAyzgtnbIr0AhlNEya+GO+42+rY0yrWG2Ffg3ONHSgylQ7hANVdk
2qAWugdXZLw/pqustIodIR3hjsWLc4zZDF+d6BywdB5WqSiS54u7ENSPkbGInKRR
8zprb2tjjjgwxL1MXF+6J1HG+GoTvEjjwjh26XDSiFbWCIX3hRjej+EjltKDARIo
RWfX6/hTVnljkNUEpBfsi7DaiDVwkgo1OLQ3OSXgG9rZxs50ASMb4dBuN8wGdRrX
jK3PF5m3ddVxCW2I5CFltd3qHlUFn+fmQojXtU6VSACgw0roQhw=
=qnbZ
-END PGP SIGNATURE-
Re: [GIT PULL] security: general updates for v4.21
On Thu, 27 Dec 2018, Linus Torvalds wrote: > On Mon, Dec 24, 2018 at 11:55 AM James Morris wrote: > > > > The main changes here are Paul Gortmaker's removal of unneccesary module.h > > infrastructure. > > I will point out a merge with a horrible commit message: > > "Sync to Linux 4.20-rc2 for downstream developers" > > that tells nobody anything. > > Why was that merge done? If you can't explain the merge, just don't do > the merge. I do this every development cycle, after requests from security subsystem maintainers to sync to -rc kernels. -- James Morris
Re: [PATCH v5 1/2] lib: add crc64 calculation routines
On Thu, Jul 26 2018, Andrew Morton wrote:
> On Thu, 26 Jul 2018 13:33:51 +0800 Coly Li wrote:
>
>> This patch adds the re-write crc64 calculation routines for Linux kernel.
>> The CRC64 polynomial arithmetic follows ECMA-182 specification, inspired
>> by CRC paper of Dr. Ross N. Williams
>> (see http://www.ross.net/crc/download/crc_v3.txt) and other public domain
>> implementations.
Hi Coly and Andrew,
This patch breaks compilation if linux headers files are not installed
(reported at https://github.com/gnubee-git/GnuBee_Docs/issues/75).
Following fixes it.
Thanks,
NeilBrown
From: NeilBrown
Subject: [PATCH] lib: don't depend on linux headers being installed.
gen_crc64table requires linux include files to be installed
in /usr/include/linux. This is a new requrement so hosts that
could previously build the kernel, now cannot.
gen_crc64table makes this requirement by including ,
but nothing from that header is actaully used.
So remove the #include, so that the linux headers no longer
need to be installed.
Fixes: feba04fd2cf8 ("lib: add crc64 calculation routines")
Signed-off-by: NeilBrown
---
lib/gen_crc64table.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/gen_crc64table.c b/lib/gen_crc64table.c
index 9011926e4162..094b43aef8db 100644
--- a/lib/gen_crc64table.c
+++ b/lib/gen_crc64table.c
@@ -16,8 +16,6 @@
#include
#include
-#include
-
#define CRC64_ECMA182_POLY 0x42F0E1EBA9EA3693ULL
static uint64_t crc64_table[256] = {0};
--
2.14.0.rc0.dirty
signature.asc
Description: PGP signature
Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM
Hi Finn,
Am 26.12.2018 um 13:37 schrieb Finn Thain:
On powerpc, setting CONFIG_NVRAM=n builds a kernel with no NVRAM support.
Setting CONFIG_NVRAM=m enables the /dev/nvram misc device module without
enabling NVRAM support in drivers. Setting CONFIG_NVRAM=y enables the
misc device (built-in) and also enables NVRAM support in drivers.
m68k shares the valkyriefb driver with powerpc, and since that driver uses
NVRAM, it is affected by CONFIG_ATARI_SCSI, because of the use of
"select NVRAM".
Adopt the powerpc convention on m68k to avoid surprises.
Signed-off-by: Finn Thain
Tested-by: Christian T. Steigies
Acked-by: Michael Schmitz
---
This patch temporarily disables CONFIG_NVRAM on Atari, to prevent build
failures when bisecting the rest of this patch series. It gets enabled
again with the introduction of CONFIG_HAVE_ARCH_NVRAM_OPS, once the
nvram_* global functions have been moved to an ops struct.
---
drivers/char/Kconfig | 5 +
drivers/scsi/Kconfig | 6 +++---
drivers/scsi/atari_scsi.c | 7 ---
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 9d03b2ff5df6..5b54595dfe30 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -236,7 +236,7 @@ source "drivers/char/hw_random/Kconfig"
config NVRAM
tristate "/dev/nvram support"
- depends on ATARI || X86 || GENERIC_NVRAM
+ depends on X86 || GENERIC_NVRAM
---help---
If you say Y here and create a character special file /dev/nvram
with major number 10 and minor number 144 using mknod ("man mknod"),
@@ -254,9 +254,6 @@ config NVRAM
should NEVER idly tamper with it. See Ralf Brown's interrupt list
for a guide to the use of CMOS bytes by your BIOS.
- On Atari machines, /dev/nvram is always configured and does not need
- to be selected.
-
To compile this driver as a module, choose M here: the
module will be called nvram.
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 640cd1b31a18..924eb69e7fc4 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1381,14 +1381,14 @@ config ATARI_SCSI
tristate "Atari native SCSI support"
depends on ATARI && SCSI
select SCSI_SPI_ATTRS
- select NVRAM
---help---
If you have an Atari with built-in NCR5380 SCSI controller (TT,
Falcon, ...) say Y to get it supported. Of course also, if you have
a compatible SCSI controller (e.g. for Medusa).
- To compile this driver as a module, choose M here: the
- module will be called atari_scsi.
+ To compile this driver as a module, choose M here: the module will
+ be called atari_scsi. If you also enable NVRAM support, the SCSI
+ host's ID is taken from the setting in TT RTC NVRAM.
This driver supports both styles of NCR integration into the
system: the TT style (separate DMA), and the Falcon style (via
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index 89f5154c40b6..99e5729d910d 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -755,9 +755,10 @@ static int __init atari_scsi_probe(struct platform_device
*pdev)
if (ATARIHW_PRESENT(TT_SCSI) && setup_sg_tablesize >= 0)
atari_scsi_template.sg_tablesize = setup_sg_tablesize;
- if (setup_hostid >= 0) {
+ if (setup_hostid >= 0)
atari_scsi_template.this_id = setup_hostid & 7;
- } else {
+#ifdef CONFIG_NVRAM
+ else
/* Test if a host id is set in the NVRam */
if (ATARIHW_PRESENT(TT_CLK) && nvram_check_checksum()) {
unsigned char b = nvram_read_byte(16);
@@ -768,7 +769,7 @@ static int __init atari_scsi_probe(struct platform_device
*pdev)
if (b & 0x80)
atari_scsi_template.this_id = b & 7;
}
- }
+#endif
/* If running on a Falcon and if there's TT-Ram (i.e., more than one
* memory block, since there's always ST-Ram in a Falcon), then
Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM
Hi Finn, Am 29.12.2018 um 15:34 schrieb Finn Thain: On Sat, 29 Dec 2018, Michael Schmitz wrote: IS_BUILTIN(CONFIG_NVRAM) is probably what Christophe really meant to suggest. Or (really going out on a limb here): IS_BUILTIN(CONFIG_NVRAM) || ( IS_MODULE(CONFIG_ATARI_SCSI) && IS_ENABLED(CONFIG_NVRAM) ) Not that I'd advocate that, for this series. Well, you are a maintainer for atari_scsi.c. Are you saying that you want IS_BUILTIN(CONFIG_NVRAM) used here instead of ifdef? No, just pointing out that there would be a way to avoid the ifdef without messing up driver behaviour. I'm fine with the ifdef - not least because it clearly eliminates code that would be unreachable. (On second thought - I don't want to speculate whether there's weird compiler options that could result in the nvram_check_checksum and nvram_read_bytes symbols to still be referenced in the final link, even though IS_BUILTIN(CONFIG_NVRAM) always evaluates to false. Best leave this as-is.) OTOH, if you approve of the existing patch, please send your acked-by. Of course - I'd seen Geert's acked-by on some of the patches and forgot to check which still required acks. Cheers, Michael
[PATCH -next] drm: Fix error handling in drm_legacy_addctx
'ctx->handle' is unsigned, it never less than zero.
This patch use int 'tmp_handle' to handle the err condition.
Fixes: 62968144e673 ("drm: convert drm context code to use Linux idr")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/drm_context.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index 506663c..8e73fab 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -361,23 +361,26 @@ int drm_legacy_addctx(struct drm_device *dev, void *data,
{
struct drm_ctx_list *ctx_entry;
struct drm_ctx *ctx = data;
+ int tmp_handle;
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
return -EOPNOTSUPP;
- ctx->handle = drm_legacy_ctxbitmap_next(dev);
- if (ctx->handle == DRM_KERNEL_CONTEXT) {
+ tmp_handle = drm_legacy_ctxbitmap_next(dev);
+ if (tmp_handle == DRM_KERNEL_CONTEXT) {
/* Skip kernel's context and get a new one. */
- ctx->handle = drm_legacy_ctxbitmap_next(dev);
+ tmp_handle = drm_legacy_ctxbitmap_next(dev);
}
- DRM_DEBUG("%d\n", ctx->handle);
- if (ctx->handle < 0) {
+ DRM_DEBUG("%d\n", tmp_handle);
+ if (tmp_handle < 0) {
DRM_DEBUG("Not enough free contexts.\n");
/* Should this return -EBUSY instead? */
- return -ENOMEM;
+ return tmp_handle;
}
+ ctx->handle = tmp_handle;
+
ctx_entry = kmalloc(sizeof(*ctx_entry), GFP_KERNEL);
if (!ctx_entry) {
DRM_DEBUG("out of memory\n");
--
2.7.0
Re: [PATCH] usb: devio: update max count of DPs per interval for ISOC
Hi,
On Fri, 2018-12-28 at 11:51 +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 28, 2018 at 06:27:44PM +0800, Chunfeng Yun wrote:
> > The host shall be able to accept and send up to 96 DPs for
> > devices operating at Gen 2 speed.
>
> Why? What is this keeping from working properly today?
The failure happened when I tried to send up to 96DPs per an interval
for SSP ISOC transations by libusb, this is used to verify SSP ISOC
function of USB3 GEN2 controller. Maybe for normal scenarios they
needn't transfer greater than 48 DPs in an ISOC interval.
(refer usb3.1r1.0 section 8.12.6 Isochronous Transactions)
>
> I need a much better changelog text here in order to be able to accept
> this patch.
I'll make the change in next version
>
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > drivers/usb/core/devio.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> > index a75bc0b8a50f..82c16210e34c 100644
> > --- a/drivers/usb/core/devio.c
> > +++ b/drivers/usb/core/devio.c
> > @@ -1564,12 +1564,10 @@ static int proc_do_submiturb(struct usb_dev_state
> > *ps, struct usbdevfs_urb *uurb
> > }
> > for (totlen = u = 0; u < number_of_packets; u++) {
> > /*
> > -* arbitrary limit need for USB 3.0
> > -* bMaxBurst (0~15 allowed, 1~16 packets)
> > -* bmAttributes (bit 1:0, mult 0~2, 1~3 packets)
> > -* sizemax: 1024 * 16 * 3 = 49152
> > +* arbitrary limit need for USB 3.1 Gen2
> > +* sizemax: 96 DPs at SSP, 96 * 1024 = 98304
> > */
> > - if (isopkt[u].length > 49152) {
> > + if (isopkt[u].length > 98304) {
>
> Are we going to have to keep bumping this up as speeds get faster and
> faster?
Or remove the check of data length? I'm not sure which way is better
>
> thanks,
>
> greg k-h
[PATCH -next] media: staging/intel-ipu3: Fix err handle of ipu3_css_find_binary
'bindex' is unsigned, it never less than zero.
This patch bring int 'binary' back to handle the err condition.
Fixes: 51abe041c5ed ("media: staging/intel-ipu3: Add dual pipe support")
Signed-off-by: YueHaibing
---
drivers/staging/media/ipu3/ipu3-css.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/ipu3/ipu3-css.c
b/drivers/staging/media/ipu3/ipu3-css.c
index 44c5563..28f0c02 100644
--- a/drivers/staging/media/ipu3/ipu3-css.c
+++ b/drivers/staging/media/ipu3/ipu3-css.c
@@ -1751,7 +1751,7 @@ int ipu3_css_fmt_try(struct ipu3_css *css,
[IPU3_CSS_QUEUE_OUT].fmt.mpix;
struct v4l2_pix_format_mplane *const vf =
[IPU3_CSS_QUEUE_VF].fmt.mpix;
- int i, s;
+ int i, s, binary;
/* Adjust all formats, get statistics buffer sizes and formats */
for (i = 0; i < IPU3_CSS_QUEUES; i++) {
@@ -1826,13 +1826,13 @@ int ipu3_css_fmt_try(struct ipu3_css *css,
s = (bds->height - gdc->height) / 2 - FILTER_SIZE;
env->height = s < MIN_ENVELOPE ? MIN_ENVELOPE : s;
- css->pipes[pipe].bindex =
- ipu3_css_find_binary(css, pipe, q, r);
- if (css->pipes[pipe].bindex < 0) {
+ binary = ipu3_css_find_binary(css, pipe, q, r);
+ if (binary < 0) {
dev_err(css->dev, "failed to find suitable binary\n");
return -EINVAL;
}
+ css->pipes[pipe].bindex = binary;
dev_dbg(css->dev, "Binary index %d for pipe %d found.",
css->pipes[pipe].bindex, pipe);
--
2.7.0
RE: [PATCH v1 0/2] Virtio: fix some vq allocation issues
On Friday, December 28, 2018 3:57 PM, Christian Borntraeger wrote: > On 28.12.2018 03:26, Wei Wang wrote: > > Some vqs don't need to be allocated when the related feature bits are > > disabled. Callers notice the vq allocation layer by setting the > > related names[i] to be NULL. > > > > This patch series fixes the find_vqs implementations to handle this case. > > So the random crashes during boot are gone. > What still does not work is actually using the balloon. > > So in the qemu monitor using lets say "balloon 1000" will hang the guest. > Seems to be a deadlock in the virtio-ccw code. We seem to call the config > code in the interrupt handler. Yes. It reads a config register from the interrupt handler. Do you know why ccw doesn't support it and has some internal lock that caused the deadlock issue? Best, Wei
BUG: unable to handle kernel paging request in slhc_free
Hello, syzbot found the following crash on: HEAD commit:8fe28cb58bcb Linux 4.20 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16771b1540 kernel config: https://syzkaller.appspot.com/x/.config?x=7d581260bae0899a dashboard link: https://syzkaller.appspot.com/bug?extid=6c5d567447bfa30f78e2 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=136130fd40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1607c56340 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+6c5d567447bfa30f7...@syzkaller.appspotmail.com RAX: ffda RBX: RCX: 00440359 RDX: 2080 RSI: 5423 RDI: 0003 RBP: 006cb018 R08: 0001 R09: 0039 R10: R11: 0246 R12: 0004 R13: R14: R15: BUG: unable to handle kernel paging request at fff4 PGD 946d067 P4D 946d067 PUD 946f067 PMD 0 Oops: [#1] PREEMPT SMP KASAN CPU: 1 PID: 8225 Comm: syz-executor096 Not tainted 4.20.0 #167 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:slhc_free+0x30/0xb0 drivers/net/slip/slhc.c:159 Code: 53 48 89 fb e8 71 04 ad fc 48 85 db 74 74 e8 67 04 ad fc 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 75 69 <4c> 8b 23 4d 85 e4 74 0d e8 43 04 ad fc 4c 89 e7 e8 bb e1 ef fc e8 RSP: 0018:8881c1a0f770 EFLAGS: 00010246 RAX: dc00 RBX: fff4 RCX: 11103408b936 RDX: 1ffe RSI: 84d15439 RDI: fff4 RBP: 8881c1a0f780 R08: 8881a045c9b0 R09: 0006 R10: R11: 8881a045c0c0 R12: ff97 R13: 8881c0ca04c0 R14: 8881c0daed00 R15: 8881c2152ac0 FS: 0078a880() GS:8881daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fff4 CR3: 0001b0909000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: sl_alloc_bufs drivers/net/slip/slip.c:196 [inline] slip_open+0xdee/0x1107 drivers/net/slip/slip.c:821 tty_ldisc_open.isra.1+0x8b/0xe0 drivers/tty/tty_ldisc.c:453 tty_set_ldisc+0x2dc/0x6a0 drivers/tty/tty_ldisc.c:578 tiocsetd drivers/tty/tty_io.c:2321 [inline] tty_ioctl+0x39d/0x17d0 drivers/tty/tty_io.c:2581 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x440359 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 14 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff63454bb8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: RCX: 00440359 RDX: 2080 RSI: 5423 RDI: 0003 RBP: 006cb018 R08: 0001 R09: 0039 R10: R11: 0246 R12: 0004 R13: R14: R15: Modules linked in: CR2: fff4 ---[ end trace 45b654871fafdc18 ]--- RIP: 0010:slhc_free+0x30/0xb0 drivers/net/slip/slhc.c:159 Code: 53 48 89 fb e8 71 04 ad fc 48 85 db 74 74 e8 67 04 ad fc 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 75 69 <4c> 8b 23 4d 85 e4 74 0d e8 43 04 ad fc 4c 89 e7 e8 bb e1 ef fc e8 RSP: 0018:8881c1a0f770 EFLAGS: 00010246 RAX: dc00 RBX: fff4 RCX: 11103408b936 RDX: 1ffe RSI: 84d15439 RDI: fff4 RBP: 8881c1a0f780 R08: 8881a045c9b0 R09: 0006 R10: R11: 8881a045c0c0 R12: ff97 R13: 8881c0ca04c0 R14: 8881c0daed00 R15: 8881c2152ac0 FS: 0078a880() GS:8881daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fff4 CR3: 0001b0909000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details
Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation
Theodore Y. Ts'o wrote on Fri, Dec 28, 2018: > > The problem is that there is no 32-bit API in some cases > > (unless I have misunderstood the kernel code) -- not all > > host architectures implement compat syscalls or allow them > > to be called from 64-bit processes or implement all the older > > syscall variants that had smaller offets. If there was a guaranteed > > "this syscall always exists and always gives me 32-bit offsets" > > we could use it. > > Are there going to be cases where a process or a thread will sometimes > want the 64-bit interface, and sometimes want the 32-bit interface? > Or is it always going to be one or the other? I wonder if we could > simply add a new flag to the process personality(2) flags. That would likely work for qemu user, but the qemu system+9p case is going to be more painful.. More precisely, the 9p protocol does not plan for anything other than 64bit offset so if the vfs needs to hand out a 32bit offset we'll need to make a correspondance table between the 32bit offsets we hand off and the 64bit ones to use; unless some flag can be passed at lopen to tell the server to always hand out 32bit offsets for this directory... And if we do that then 9p servers will need a way to use both APIs in parallel for both types of directories. (Although I'd rather not have to do either in the first place, keeping track of all used offsets just in case seems like a waste even if we only do it for processes in 32bit mode, and a new flag would be a protocol change with 9p not being designed to catter for subtle protocol changes so would be rather painful to roll out) No bright idea here, sorry. -- Dominique Martinet | Asmadeus
Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM
On Sat, 29 Dec 2018, Michael Schmitz wrote: > > IS_BUILTIN(CONFIG_NVRAM) is probably what Christophe really meant to suggest. > > Or (really going out on a limb here): > > IS_BUILTIN(CONFIG_NVRAM) || > ( IS_MODULE(CONFIG_ATARI_SCSI) && IS_ENABLED(CONFIG_NVRAM) ) > > Not that I'd advocate that, for this series. > Well, you are a maintainer for atari_scsi.c. Are you saying that you want IS_BUILTIN(CONFIG_NVRAM) used here instead of ifdef? OTOH, if you approve of the existing patch, please send your acked-by. -- > Cheers, > > Michael > > > >
Re: How to force RC to forward p2p TLPs
[+cc Logan, Stephen, Jonathan, Eric, Alex] On Sat, Dec 22, 2018 at 12:50:19PM +0800, yu wrote: > Hi all, > > We have a PCIE card which has a PEX8732 switch on-board, and there > are two endpoint SOCs like graphic decoder behind the switch, and by > default the ACS is enabled in 8732. > > We use the p2p DMA to transfer data between these two endpoint SOCs, > and if the host server is not enable ACS in BIOS, the p2p works well, > but when ACS is enabled in BIOS, the p2p is always failed. With the > help of a protocol analyzer, we can see that the TLP is redirected to > RC, and RC just discard it. > > I tried to find how to make RC forward redirected TLP to its original > target, but nothing found, it seems this is highly related to the RC > vendors. > > In the PCIE 4.0 spec, the section of the RC behavior of the p2p > request redirect said that ''implementation-specific logic within the > RC that determines whether the request is directed towards its > original target, or blocked as an ACS Violation error. the algorithms > and specific controls for making this determination are not > architected by this spec''. > > > So is there some spec or document to describe how to set the RC? Any > suggestion is appreciated. Not that I'm aware of, but the folks I cc'd would know a lot more about this area. Bjorn
Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation
On Fri, Dec 28, 2018 at 11:18:18AM +, Peter Maydell wrote: > In general inodes and offsets start from 0 and work up -- > so almost all of the time they don't actually overflow. > The problem with ext4 directory hash "offsets" is that they > overflow all the time and immediately, so instead of "works > unless you have a weird edge case" like all the other filesystems,h > it's "never works". Actually, XFS uses the inode number to encode the location of the inode (it doesn't have a fixed inode table, so it's effectively the block number shifted left by 3 or 4 bits, with the low bits indicating the slot in the 4k block). It has a hack to provide backwards compatibility for 32-bit API's, but there is a similar, "oh, we're on a non-paleolithic CPU, let's use the full 64-bits" sort of logic that ext4 has. > The problem is that there is no 32-bit API in some cases > (unless I have misunderstood the kernel code) -- not all > host architectures implement compat syscalls or allow them > to be called from 64-bit processes or implement all the older > syscall variants that had smaller offets. If there was a guaranteed > "this syscall always exists and always gives me 32-bit offsets" > we could use it. Are there going to be cases where a process or a thread will sometimes want the 64-bit interface, and sometimes want the 32-bit interface? Or is it always going to be one or the other? I wonder if we could simply add a new flag to the process personality(2) flags. > Yes, that has been suggested, but it seemed a bit dubious > to bake in knowledge of ext4's internal implementation details. > Can we rely on this as an ABI promise that will always work > for all versions of all file systems going forwards? Yeah, that seems dubious because I'm pretty sure there are other file systems that may have their own 32/64-bit quirks. - Ted
Re: [PATCH v3 treewide] headers: separate linux/mod_devicetable.h from linux/platform_device.h
On 12/28/18 5:32 PM, NeilBrown wrote:
> On Sat, Jul 07 2018, Greg Kroah-Hartman wrote:
>
>> On Tue, Jun 19, 2018 at 10:47:28PM -0700, Randy Dunlap wrote:
>>> From: Randy Dunlap
>>>
>>> At over 4000 #includes, is the 9th most
>>> #included header file in the Linux kernel. It does not need
>>> , so drop that header and explicitly add
>>> to source files that need it.
>>>
>>>4146 #include
>>>
>>> After this patch, there are 225 files that use ,
>>> for a reduction of around 3900 times that
>>> does not have to be read & parsed.
>>>
>>> 225 #include
>>>
>>> This patch was build-tested on 20 different arch-es.
>>>
>>> It also makes these drivers SubmitChecklist#1 compliant.
>>>
>>> Signed-off-by: Randy Dunlap
>>> Reported-by: kbuild test robot #
>>> drivers/media/platform/vimc/
>>> Reported-by: kbuild test robot #
>>> drivers/pinctrl/pinctrl-u300.c
>>> ---
>>> v3: add fix for drivers/pinctrl/pinctrl-u300.c
>>> v2: add fixes for drivers/media/platform/vimc/
>>
>> I've queued this up now, let's see what else breaks! :)
>
> Some MIPS watchdog drivers break, at least.
>
> NeilBrown
>
> From: NeilBrown
> Subject: [PATCH] Fix compilation problem for mt7621_wdt.c and rt2880_wdt.c
>
> These files need
>#include
> to compile correctly.
>
> Fixes: ac3167257b9f ("headers: separate linux/mod_devicetable.h from
> linux/platform_device.h")
> Signed-off-by: NeilBrown
Thanks, NeilBrown.
> ---
> drivers/watchdog/mt7621_wdt.c | 1 +
> drivers/watchdog/rt2880_wdt.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/watchdog/mt7621_wdt.c b/drivers/watchdog/mt7621_wdt.c
> index 5c4a764717c4..81208cd3f4ec 100644
> --- a/drivers/watchdog/mt7621_wdt.c
> +++ b/drivers/watchdog/mt7621_wdt.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> diff --git a/drivers/watchdog/rt2880_wdt.c b/drivers/watchdog/rt2880_wdt.c
> index 98967f0a7d10..db7c57d82cfd 100644
> --- a/drivers/watchdog/rt2880_wdt.c
> +++ b/drivers/watchdog/rt2880_wdt.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
>
--
~Randy
RE: [PATCH] net: tsn: add an netlink interface between kernel and application layer
Hi Vinicius, Thank you very much for your feedback. I know the CBS is used to be most important part of AVB. And qdiscs is good tool to configure qos. But as you know, the TSN family is a cluster of protocols and much extending the AVB. The protocols have different functionalities and they may have more than hundred parameters. For example NXP ls1028a support Qbv/Qci/Qbu/Qav and also the 8021CB (not included in this patch yet). Some protocols target to configure the traffic class(like Qav CBS). Some to config the port(like Qbv). But some for the whole ethernet controller(like Qci, the control entries for the whole controller, which input ports and which output ports). So I do think all the TSN configuration should not mix in the ethernet driver itself. I mean the driver should separate a xxx_tsn.c(for I210, may igb_tsn.c) to maintain the tsn operations. As far as using qdiscs or the interface of generic netlink. I think both could configuring the TSN protocols interface layer. Just what I provided the patch net/tsn/genl_tsn.c. But I do believe it is better using a standalone TSN middle layer to maintain the TSN capability ports. Because the TSN ports include not only the end station and also the switch. LS1028 is such a kind of device. And your advises are precious for us. Let's make out an easy and flexible interface for TSN. Br, Po Liu > -Original Message- > From: Vinicius Costa Gomes [mailto:vinicius.go...@intel.com] > Sent: 2018年12月29日 3:30 > To: PO LIU ; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: da...@davemloft.net; haus...@cisco.com; nicolas.fe...@microchip.com; > gre...@linuxfoundation.org; Mingkai Hu ; Roy Zang > ; PO LIU ; PO LIU > Subject: Re: [PATCH] net: tsn: add an netlink interface between kernel and > application layer > > Hi, > > PO LIU writes: > > > This patch provids netlink method to configure the TSN protocols hardwares. > > TSN guaranteed packet transport with bounded low latency, low packet > > delay variation, and low packet loss by hardware and software methods. > > I don't think having another way to configure TSN features is a good idea. We > already have the CBS/ETF/taprio family of qdiscs, that provide (or will in the > near future, more on this later) a way to configure the hardware. > > A little background on the choice of qdiscs as an interface (and why we came > to > believe they are a good abstraction), they already provide a way to map > packets into traffic classes (it isn't clear in our proposal how you do that, > but I > think you are using something like mqprio), they provide a neat way to > "compose" (by installing one under another), they already have a user facing > API with various counters, and very importantly for TSN they have mecanisms > to offload some of their work to the hardware. > > I suggest is for you to take a look at how CBS offloading was implemented for > the Intel i210: > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch > work.ozlabs.org%2Fcover%2F824626%2Fdata=02%7C01%7Cpo.liu%40n > xp.com%7C107e693326214900cf0708d66cfadace%7C686ea1d3bc2b4c6fa92c > d99c5c301635%7C0%7C0%7C636816222009310445sdata=6O1s%2Bd% > 2BbNek1Ko7a5ev0txiw8S6TiVeUrUWZlOXDnAw%3Dreserved=0 > > Patches 4 and 5 should be the interesting ones. I think you can use them as > inspiration for enabling CBS offload in your driver. > > If you did take a look at those patches (and the current work that has been > upstreamed), my question then becomes, what are the reasons that it might > not work for your use cases? > > > > > The three basic components of TSN are: > > > > 1. Time synchronization: This was implement by 8021AS which base on the > >IEEE1588 precision Time Protocol. This is configured by the other way > >in kernel. > >8021AS not included in this patch. > > > > 2. Scheduling and traffic shaping and per-stream filter policing: > >This patch support Qbv/Qci. > > I am working on a proposal for the API for Qbv (and Qbu) offloading using > taprio. I should send it soon-ish. Your feedback would be very welcome. > > Also, how to expose in the qdiscs the per-stream filtering and policing parts > (Qci) > is something that I don't know how to do right now, any suggestions would be > nice. > > In short, take a look at what's there and see what's missing for the stuff > that > you care about, then we can work on that. > > > > > 3. Selection of communication paths: > >This patch not support the pure software only TSN protocols(like Qcc) > >but hardware related configuration. > > > > TSN Protocols supports by this patch: Qbv/Qci/Qbu/Credit-base Shaper(Qav). > > This patch verified on NXP ls1028ardb board. > > > > Will add more protocols in the future. > > > > Signed-off-by: Po Liu > > > Cheers, > -- > Vinicius
[PATCH] Documentation: rename addr_in_gen_pool to gen_pool_has_addr
Update the document, since we have renamed addr_in_gen_pool to gen_pool_has_addr. Signed-off-by: Huang Shijie --- Sorry, I missed to update this document... --- Documentation/core-api/genalloc.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/core-api/genalloc.rst b/Documentation/core-api/genalloc.rst index 6b38a39fab24..a534cc7ebd05 100644 --- a/Documentation/core-api/genalloc.rst +++ b/Documentation/core-api/genalloc.rst @@ -129,7 +129,7 @@ writing of special-purpose memory allocators in the future. :functions: gen_pool_for_each_chunk .. kernel-doc:: lib/genalloc.c - :functions: addr_in_gen_pool + :functions: gen_pool_has_addr .. kernel-doc:: lib/genalloc.c :functions: gen_pool_avail -- 2.17.1
[PATCH] netfilter: account ebt_table_info to kmemcg
The [ip,ip6,arp]_tables use x_tables_info internally and the underlying
memory is already accounted to kmemcg. Do the same for ebtables. The
syzbot, by using setsockopt(EBT_SO_SET_ENTRIES), was able to OOM the
whole system from a restricted memcg, a potential DoS.
Reported-by: syzbot+7713f3aa67be76b15...@syzkaller.appspotmail.com
Signed-off-by: Shakeel Butt
---
net/bridge/netfilter/ebtables.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 491828713e0b..5e55cef0cec3 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1137,14 +1137,16 @@ static int do_replace(struct net *net, const void
__user *user,
tmp.name[sizeof(tmp.name) - 1] = 0;
countersize = COUNTER_OFFSET(tmp.nentries) * nr_cpu_ids;
- newinfo = vmalloc(sizeof(*newinfo) + countersize);
+ newinfo = __vmalloc(sizeof(*newinfo) + countersize, GFP_KERNEL_ACCOUNT,
+ PAGE_KERNEL);
if (!newinfo)
return -ENOMEM;
if (countersize)
memset(newinfo->counters, 0, countersize);
- newinfo->entries = vmalloc(tmp.entries_size);
+ newinfo->entries = __vmalloc(tmp.entries_size, GFP_KERNEL_ACCOUNT,
+PAGE_KERNEL);
if (!newinfo->entries) {
ret = -ENOMEM;
goto free_newinfo;
--
2.20.1.415.g653613c723-goog
Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation
On Sat, Dec 29, 2018 at 12:12:27AM +, Peter Maydell wrote: > On Fri, 28 Dec 2018 at 23:16, Andreas Dilger wrot > > On Dec 28, 2018, at 4:18 AM, Peter Maydell wrote: > > > The problem is that there is no 32-bit API in some cases > > > (unless I have misunderstood the kernel code) -- not all > > > host architectures implement compat syscalls or allow them > > > to be called from 64-bit processes or implement all the older > > > syscall variants that had smaller offets. If there was a guaranteed > > > "this syscall always exists and always gives me 32-bit offsets" > > > we could use it. > > > > The "32bitapi" mount option would use 32-bit hash for seekdir > > and telldir, regardless of what kernel API was used. That would > > just set the FMODE_32BITHASH flag in the file->f_mode for all files. > > A mount option wouldn't be much use to QEMU -- we can't tell > our users how to mount their filesystems, which they're > often doing lots of other things with besides running QEMU. > (Otherwise we could just tell them "don't use ext4", which > would also solve the problem :-)) We need something we can > use at the individual-syscall level. Could you use a prctl to set whether you were running in 32 or 64 bit mode? Or do you change which kind of task you're emulating too often to make this a good idea?
Re: [PATCH] netfilter: fix a missing check of nla put failure
On Fri, Dec 21, 2018 at 12:46:23AM -0600, Kangjie Lu wrote: > If nla_nest_start() may fail. The fix checks its return value and goes > to nla_put_failure if it fails. Applied, thanks.
Re: [v3 PATCH 1/2] mm: swap: check if swap backing device is congested or not
On 12/28/18 4:42 PM, Andrew Morton wrote: On Sat, 22 Dec 2018 05:40:19 +0800 Yang Shi wrote: Swap readahead would read in a few pages regardless if the underlying device is busy or not. It may incur long waiting time if the device is congested, and it may also exacerbate the congestion. Use inode_read_congested() to check if the underlying device is busy or not like what file page readahead does. Get inode from swap_info_struct. Although we can add inode information in swap_address_space (address_space->host), it may lead some unexpected side effect, i.e. it may break mapping_cap_account_dirty(). Using inode from swap_info_struct seems simple and good enough. Just does the check in vma_cluster_readahead() since swap_vma_readahead() is just used for non-rotational device which much less likely has congestion than traditional HDD. Although swap slots may be consecutive on swap partition, it still may be fragmented on swap file. This check would help to reduce excessive stall for such case. Some words about the observed effects of the patch would be more than appropriate! Yes, sure. Actually, this could reduce the latency long tail of do_swap_page() on a congested system. The test on my virtual machine with emulated HDD shows: Without swap congestion check: page_fault1_thr-1490 [023] 129.311706: funcgraph_entry: # 57377.796 us | do_swap_page(); page_fault1_thr-1490 [023] 129.369103: funcgraph_entry: 5.642 us | do_swap_page(); page_fault1_thr-1490 [023] 129.369119: funcgraph_entry: # 1289.592 us | do_swap_page(); page_fault1_thr-1490 [023] 129.370411: funcgraph_entry: 4.957 us | do_swap_page(); page_fault1_thr-1490 [023] 129.370419: funcgraph_entry: 1.940 us | do_swap_page(); page_fault1_thr-1490 [023] 129.378847: funcgraph_entry: # 1411.385 us | do_swap_page(); page_fault1_thr-1490 [023] 129.380262: funcgraph_entry: 3.916 us | do_swap_page(); page_fault1_thr-1490 [023] 129.380275: funcgraph_entry: # 4287.751 us | do_swap_page(); With swap congestion check: runtest.py-1417 [020] 301.925911: funcgraph_entry: # 9870.146 us | do_swap_page(); runtest.py-1417 [020] 301.935785: funcgraph_entry: 9.802 us | do_swap_page(); runtest.py-1417 [020] 301.935799: funcgraph_entry: 3.551 us | do_swap_page(); runtest.py-1417 [020] 301.935806: funcgraph_entry: 2.142 us | do_swap_page(); runtest.py-1417 [020] 301.935853: funcgraph_entry: 6.938 us | do_swap_page(); runtest.py-1417 [020] 301.935864: funcgraph_entry: 3.765 us | do_swap_page(); runtest.py-1417 [020] 301.935871: funcgraph_entry: 3.600 us | do_swap_page(); runtest.py-1417 [020] 301.935878: funcgraph_entry: 7.202 us | do_swap_page(); The long tail latency (>1000us) is reduced significantly. BTW, do you need I resend the patch with the above information appended into the commit log? Thanks, Yang
Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM
Hi Finn,
Am 29.12.2018 um 14:06 schrieb Finn Thain:
On Fri, 28 Dec 2018, LEROY Christophe wrote:
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index 89f5154c40b6..99e5729d910d 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -755,9 +755,10 @@ static int __init atari_scsi_probe(struct
platform_device *pdev)
if (ATARIHW_PRESENT(TT_SCSI) && setup_sg_tablesize >= 0)
atari_scsi_template.sg_tablesize = setup_sg_tablesize;
- if (setup_hostid >= 0) {
+ if (setup_hostid >= 0)
atari_scsi_template.this_id = setup_hostid & 7;
- } else {
+#ifdef CONFIG_NVRAM
+ else
Such ifdefs should be avoided in C files.
It would be better to use
} else if (IS_ENABLED(CONFIG_NVRAM)) {
I don't like #ifdefs either. However, as the maintainer of this file, I am
okay with this one.
The old #ifdef CONFIG_NVRAM conditional compilation convention that gets
used here and under drivers/video/fbdev could probably be improved upon
but I consider this to be out-of-scope for this series, which is
complicated enough.
And as explained in the commit log, CONFIG_NVRAM=y and CONFIG_NVRAM=m are
treaded differently by drivers. Therefore, IS_ENABLED would be incorrect.
IS_BUILTIN(CONFIG_NVRAM) is probably what Christophe really meant to
suggest.
Or (really going out on a limb here):
IS_BUILTIN(CONFIG_NVRAM) ||
( IS_MODULE(CONFIG_ATARI_SCSI) && IS_ENABLED(CONFIG_NVRAM) )
Not that I'd advocate that, for this series.
Cheers,
Michael
Re: [PATCH v3 treewide] headers: separate linux/mod_devicetable.h from linux/platform_device.h
On Sat, Jul 07 2018, Greg Kroah-Hartman wrote:
> On Tue, Jun 19, 2018 at 10:47:28PM -0700, Randy Dunlap wrote:
>> From: Randy Dunlap
>>
>> At over 4000 #includes, is the 9th most
>> #included header file in the Linux kernel. It does not need
>> , so drop that header and explicitly add
>> to source files that need it.
>>
>>4146 #include
>>
>> After this patch, there are 225 files that use ,
>> for a reduction of around 3900 times that
>> does not have to be read & parsed.
>>
>> 225 #include
>>
>> This patch was build-tested on 20 different arch-es.
>>
>> It also makes these drivers SubmitChecklist#1 compliant.
>>
>> Signed-off-by: Randy Dunlap
>> Reported-by: kbuild test robot #
>> drivers/media/platform/vimc/
>> Reported-by: kbuild test robot #
>> drivers/pinctrl/pinctrl-u300.c
>> ---
>> v3: add fix for drivers/pinctrl/pinctrl-u300.c
>> v2: add fixes for drivers/media/platform/vimc/
>
> I've queued this up now, let's see what else breaks! :)
Some MIPS watchdog drivers break, at least.
NeilBrown
From: NeilBrown
Subject: [PATCH] Fix compilation problem for mt7621_wdt.c and rt2880_wdt.c
These files need
#include
to compile correctly.
Fixes: ac3167257b9f ("headers: separate linux/mod_devicetable.h from
linux/platform_device.h")
Signed-off-by: NeilBrown
---
drivers/watchdog/mt7621_wdt.c | 1 +
drivers/watchdog/rt2880_wdt.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/watchdog/mt7621_wdt.c b/drivers/watchdog/mt7621_wdt.c
index 5c4a764717c4..81208cd3f4ec 100644
--- a/drivers/watchdog/mt7621_wdt.c
+++ b/drivers/watchdog/mt7621_wdt.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
diff --git a/drivers/watchdog/rt2880_wdt.c b/drivers/watchdog/rt2880_wdt.c
index 98967f0a7d10..db7c57d82cfd 100644
--- a/drivers/watchdog/rt2880_wdt.c
+++ b/drivers/watchdog/rt2880_wdt.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
--
2.14.0.rc0.dirty
signature.asc
Description: PGP signature
[PATCH] percpu: plumb gfp flag to pcpu_get_pages
__alloc_percpu_gfp() can be called from atomic context, so, make
pcpu_get_pages use the gfp provided to the higher layer.
Signed-off-by: Shakeel Butt
---
mm/percpu-vm.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
index d8078de912de..4f42c4c5c902 100644
--- a/mm/percpu-vm.c
+++ b/mm/percpu-vm.c
@@ -21,6 +21,7 @@ static struct page *pcpu_chunk_page(struct pcpu_chunk *chunk,
/**
* pcpu_get_pages - get temp pages array
+ * @gfp: allocation flags passed to the underlying allocator
*
* Returns pointer to array of pointers to struct page which can be indexed
* with pcpu_page_idx(). Note that there is only one array and accesses
@@ -29,7 +30,7 @@ static struct page *pcpu_chunk_page(struct pcpu_chunk *chunk,
* RETURNS:
* Pointer to temp pages array on success.
*/
-static struct page **pcpu_get_pages(void)
+static struct page **pcpu_get_pages(gfp_t gfp)
{
static struct page **pages;
size_t pages_size = pcpu_nr_units * pcpu_unit_pages * sizeof(pages[0]);
@@ -37,7 +38,7 @@ static struct page **pcpu_get_pages(void)
lockdep_assert_held(_alloc_mutex);
if (!pages)
- pages = pcpu_mem_zalloc(pages_size, GFP_KERNEL);
+ pages = pcpu_mem_zalloc(pages_size, gfp);
return pages;
}
@@ -278,7 +279,7 @@ static int pcpu_populate_chunk(struct pcpu_chunk *chunk,
{
struct page **pages;
- pages = pcpu_get_pages();
+ pages = pcpu_get_pages(gfp);
if (!pages)
return -ENOMEM;
@@ -316,7 +317,7 @@ static void pcpu_depopulate_chunk(struct pcpu_chunk *chunk,
* successful population attempt so the temp pages array must
* be available now.
*/
- pages = pcpu_get_pages();
+ pages = pcpu_get_pages(GFP_KERNEL);
BUG_ON(!pages);
/* unmap and free */
--
2.20.1.415.g653613c723-goog
Re: [GIT PULL] y2038: more syscalls and cleanups
The pull request you sent on Fri, 21 Dec 2018 00:09:43 +0100: > (unable to parse the git remote) has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b12a9124eeb71d766a3e3eb594ebbb3fefc66902 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] MMC updates for v4.21
The pull request you sent on Thu, 27 Dec 2018 15:31:52 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/00d59fde8532b2d42e80909d2e58678755e04da9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Mon, 24 Dec 2018 22:16:14 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5d24ae67a961c51beb255a28c9c417d9710247c2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] first round of SCSI updates for the 4.20+ merge window
The pull request you sent on Mon, 24 Dec 2018 09:19:53 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/938edb8a31b976c9a92eb0cd4ff481e93f76c1f1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] dma-mapping updates for Linux 4.21
The pull request you sent on Fri, 21 Dec 2018 10:45:49 +0100: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/af7ddd8a627c62a835524b3f5b471edbbbcce025 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v8 02/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
On Fri, 28 Dec 2018, LEROY Christophe wrote:
> Finn Thain a ?crit?:
>
> > Move the m68k-specific code out of the driver to make the driver generic.
> >
> > I've used 'SPDX-License-Identifier: GPL-2.0+' for the new file because the
> > old file is covered by MODULE_LICENSE("GPL").
> >
> > Signed-off-by: Finn Thain
> > Tested-by: Christian T. Steigies
> > Acked-by: Geert Uytterhoeven
> > ---
> > Changed since v7:
> > - Added SPDX-License-Identifier.
> > ---
> > arch/m68k/atari/Makefile | 2 +
> > arch/m68k/atari/nvram.c | 243 +
> > drivers/char/nvram.c | 280 +--
> > 3 files changed, 280 insertions(+), 245 deletions(-)
> > create mode 100644 arch/m68k/atari/nvram.c
> >
> > diff --git a/arch/m68k/atari/Makefile b/arch/m68k/atari/Makefile
> > index 0cac723306f9..0b86bb6cfa87 100644
> > --- a/arch/m68k/atari/Makefile
> > +++ b/arch/m68k/atari/Makefile
> > @@ -6,3 +6,5 @@ obj-y := config.o time.o debug.o ataints.o
> > stdma.o \
> > atasound.o stram.o
> >
> > obj-$(CONFIG_ATARI_KBD_CORE) += atakeyb.o
> > +
> > +obj-$(CONFIG_NVRAM:m=y)+= nvram.o
> > diff --git a/arch/m68k/atari/nvram.c b/arch/m68k/atari/nvram.c
> > new file mode 100644
> > index ..3e620ee955ba
> > --- /dev/null
> > +++ b/arch/m68k/atari/nvram.c
> > @@ -0,0 +1,243 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * CMOS/NV-RAM driver for Atari. Adapted from drivers/char/nvram.c.
> > + * Copyright (C) 1997 Roman Hodek
> > + * idea by and with help from Richard Jelinek
> > + * Portions copyright (c) 2001,2002 Sun Microsystems (thoc...@sun.com)
> > + * Further contributions from Cesar Barros, Erik Gilling, Tim Hockin and
> > + * Wim Van Sebroeck.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define NVRAM_BYTES50
> > +
> > +/* It is worth noting that these functions all access bytes of general
> > + * purpose memory in the NVRAM - that is to say, they all add the
> > + * NVRAM_FIRST_BYTE offset. Pass them offsets into NVRAM as if you did not
> > + * know about the RTC cruft.
> > + */
> > +
> > +/* Note that *all* calls to CMOS_READ and CMOS_WRITE must be done with
> > + * rtc_lock held. Due to the index-port/data-port design of the RTC, we
> > + * don't want two different things trying to get to it at once. (e.g. the
> > + * periodic 11 min sync from kernel/time/ntp.c vs. this driver.)
> > + */
> > +
> > +unsigned char __nvram_read_byte(int i)
> > +{
> > + return CMOS_READ(NVRAM_FIRST_BYTE + i);
> > +}
> > +
> > +unsigned char nvram_read_byte(int i)
> > +{
> > + unsigned long flags;
> > + unsigned char c;
> > +
> > + spin_lock_irqsave(_lock, flags);
> > + c = __nvram_read_byte(i);
> > + spin_unlock_irqrestore(_lock, flags);
> > + return c;
> > +}
> > +EXPORT_SYMBOL(nvram_read_byte);
> > +
> > +/* This races nicely with trying to read with checksum checking */
> > +void __nvram_write_byte(unsigned char c, int i)
> > +{
> > + CMOS_WRITE(c, NVRAM_FIRST_BYTE + i);
> > +}
> > +
> > +void nvram_write_byte(unsigned char c, int i)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(_lock, flags);
> > + __nvram_write_byte(c, i);
> > + spin_unlock_irqrestore(_lock, flags);
> > +}
> > +
> > +/* On Ataris, the checksum is over all bytes except the checksum bytes
> > + * themselves; these are at the very end.
> > + */
> > +#define ATARI_CKS_RANGE_START 0
> > +#define ATARI_CKS_RANGE_END47
> > +#define ATARI_CKS_LOC 48
> > +
> > +int __nvram_check_checksum(void)
> > +{
> > + int i;
> > + unsigned char sum = 0;
> > +
> > + for (i = ATARI_CKS_RANGE_START; i <= ATARI_CKS_RANGE_END; ++i)
> > + sum += __nvram_read_byte(i);
> > + return (__nvram_read_byte(ATARI_CKS_LOC) == (~sum & 0xff)) &&
> > + (__nvram_read_byte(ATARI_CKS_LOC + 1) == (sum & 0xff));
> > +}
> > +
> > +int nvram_check_checksum(void)
> > +{
> > + unsigned long flags;
> > + int rv;
> > +
> > + spin_lock_irqsave(_lock, flags);
> > + rv = __nvram_check_checksum();
> > + spin_unlock_irqrestore(_lock, flags);
> > + return rv;
> > +}
> > +EXPORT_SYMBOL(nvram_check_checksum);
> > +
> > +static void __nvram_set_checksum(void)
> > +{
> > + int i;
> > + unsigned char sum = 0;
> > +
> > + for (i = ATARI_CKS_RANGE_START; i <= ATARI_CKS_RANGE_END; ++i)
> > + sum += __nvram_read_byte(i);
> > + __nvram_write_byte(~sum, ATARI_CKS_LOC);
> > + __nvram_write_byte(sum, ATARI_CKS_LOC + 1);
> > +}
> > +
> > +#ifdef CONFIG_PROC_FS
> > +static struct {
> > + unsigned char val;
> > + const char *name;
> > +} boot_prefs[] = {
> > + { 0x80, "TOS" },
> > + { 0x40, "ASV" },
> > + { 0x20, "NetBSD (?)" },
> > + { 0x10, "Linux" },
> > + { 0x00, "unspecified" },
> > +};
> > +
> > +static
Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM
On Fri, 28 Dec 2018, LEROY Christophe wrote:
> Finn Thain a ?crit?:
>
> > On powerpc, setting CONFIG_NVRAM=n builds a kernel with no NVRAM support.
> > Setting CONFIG_NVRAM=m enables the /dev/nvram misc device module without
> > enabling NVRAM support in drivers. Setting CONFIG_NVRAM=y enables the
> > misc device (built-in) and also enables NVRAM support in drivers.
> >
> > m68k shares the valkyriefb driver with powerpc, and since that driver uses
> > NVRAM, it is affected by CONFIG_ATARI_SCSI, because of the use of
> > "select NVRAM".
> >
> > Adopt the powerpc convention on m68k to avoid surprises.
> >
> > Signed-off-by: Finn Thain
> > Tested-by: Christian T. Steigies
> > ---
> > This patch temporarily disables CONFIG_NVRAM on Atari, to prevent build
> > failures when bisecting the rest of this patch series. It gets enabled
> > again with the introduction of CONFIG_HAVE_ARCH_NVRAM_OPS, once the
> > nvram_* global functions have been moved to an ops struct.
> > ---
> > drivers/char/Kconfig | 5 +
> > drivers/scsi/Kconfig | 6 +++---
> > drivers/scsi/atari_scsi.c | 7 ---
> > 3 files changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> > index 9d03b2ff5df6..5b54595dfe30 100644
> > --- a/drivers/char/Kconfig
> > +++ b/drivers/char/Kconfig
> > @@ -236,7 +236,7 @@ source "drivers/char/hw_random/Kconfig"
> >
> > config NVRAM
> > tristate "/dev/nvram support"
> > - depends on ATARI || X86 || GENERIC_NVRAM
> > + depends on X86 || GENERIC_NVRAM
> > ---help---
> > If you say Y here and create a character special file /dev/nvram
> > with major number 10 and minor number 144 using mknod ("man mknod"),
> > @@ -254,9 +254,6 @@ config NVRAM
> > should NEVER idly tamper with it. See Ralf Brown's interrupt list
> > for a guide to the use of CMOS bytes by your BIOS.
> >
> > - On Atari machines, /dev/nvram is always configured and does not need
> > - to be selected.
> > -
> > To compile this driver as a module, choose M here: the
> > module will be called nvram.
> >
> > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> > index 640cd1b31a18..924eb69e7fc4 100644
> > --- a/drivers/scsi/Kconfig
> > +++ b/drivers/scsi/Kconfig
> > @@ -1381,14 +1381,14 @@ config ATARI_SCSI
> > tristate "Atari native SCSI support"
> > depends on ATARI && SCSI
> > select SCSI_SPI_ATTRS
> > - select NVRAM
> > ---help---
> > If you have an Atari with built-in NCR5380 SCSI controller (TT,
> > Falcon, ...) say Y to get it supported. Of course also, if you have
> > a compatible SCSI controller (e.g. for Medusa).
> >
> > - To compile this driver as a module, choose M here: the
> > - module will be called atari_scsi.
> > + To compile this driver as a module, choose M here: the module will
> > + be called atari_scsi. If you also enable NVRAM support, the SCSI
> > + host's ID is taken from the setting in TT RTC NVRAM.
> >
> > This driver supports both styles of NCR integration into the
> > system: the TT style (separate DMA), and the Falcon style (via
> > diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
> > index 89f5154c40b6..99e5729d910d 100644
> > --- a/drivers/scsi/atari_scsi.c
> > +++ b/drivers/scsi/atari_scsi.c
> > @@ -755,9 +755,10 @@ static int __init atari_scsi_probe(struct
> > platform_device *pdev)
> > if (ATARIHW_PRESENT(TT_SCSI) && setup_sg_tablesize >= 0)
> > atari_scsi_template.sg_tablesize = setup_sg_tablesize;
> >
> > - if (setup_hostid >= 0) {
> > + if (setup_hostid >= 0)
> > atari_scsi_template.this_id = setup_hostid & 7;
> > - } else {
> > +#ifdef CONFIG_NVRAM
> > + else
>
> Such ifdefs should be avoided in C files.
> It would be better to use
>
> } else if (IS_ENABLED(CONFIG_NVRAM)) {
>
I don't like #ifdefs either. However, as the maintainer of this file, I am
okay with this one.
The old #ifdef CONFIG_NVRAM conditional compilation convention that gets
used here and under drivers/video/fbdev could probably be improved upon
but I consider this to be out-of-scope for this series, which is
complicated enough.
And as explained in the commit log, CONFIG_NVRAM=y and CONFIG_NVRAM=m are
treaded differently by drivers. Therefore, IS_ENABLED would be incorrect.
--
> > /* Test if a host id is set in the NVRam */
> > if (ATARIHW_PRESENT(TT_CLK) && nvram_check_checksum()) {
> > unsigned char b = nvram_read_byte(16);
> > @@ -768,7 +769,7 @@ static int __init atari_scsi_probe(struct
> > platform_device *pdev)
> > if (b & 0x80)
> > atari_scsi_template.this_id = b & 7;
> > }
> > - }
> > +#endif
> >
> > /* If running on a Falcon and if there's TT-Ram (i.e., more than one
> > * memory block, since there's always ST-Ram in a Falcon), then
> > --
> > 2.19.2
>
>
>
Re: [PATCH RFC lora-next 2/4] net: lora: sx1301: add minimal to get AGC working prior to tx work
Hi Ben,
Am 19.12.18 um 16:56 schrieb Ben Whitten:
> As part of initialisation when opening the lora device after loading
> the AGC firmware we need to satisfy its startup procedure which involves
> a few steps;
>
> Loading a 16 entry lookup table.
> For this I have hard coded the laird ETSI certified table for use on the
> RG186-M2 (EU) cards, this will need investigation on how other devices
> load calibration data.
Isn't calibration performed before this firmware is initialized? I left
out reading the values back from firmware previously, but that should
get implemented. In the userspace implementation, do you get these from
a config file or did you modify the reference code to hardcode them?
If these are different calibration values from the ones returned by
firmware, then a DT property would be an easy way to get
hardware-specific data into the driver. However, same as with your clk
config, that makes us dependent on DT, which we shouldn't be for ACPI
and USB. If we consider it configuration data rather than an immutable
fact, then we would need a netlink command to set them.
In any case, we have some other vendors on this list, so hopefully
someone can comment. :)
>
> Selecting the correct channel to transmit on.
> Currently always 0 for the reference design.
Similarly: DT or netlink depending on whether fixed, and fall back to 0
as default.
>
> Then ending the AGC init procedure and seeing that it has come up.
>
> Signed-off-by: Ben Whitten
> ---
> drivers/net/lora/sx1301.c | 254 +-
> drivers/net/lora/sx1301.h | 16 +++
> 2 files changed, 268 insertions(+), 2 deletions(-)
Many thanks for working on this! Some nits inline.
> diff --git a/drivers/net/lora/sx1301.c b/drivers/net/lora/sx1301.c
> index e75df93b96d8..0c7b6d0b31af 100644
> --- a/drivers/net/lora/sx1301.c
> +++ b/drivers/net/lora/sx1301.c
> @@ -24,6 +24,121 @@
>
> #include "sx1301.h"
>
> +static struct sx1301_tx_gain_lut tx_gain_lut[] = {
> + {
> + .dig_gain = 0,
> + .pa_gain = 0,
> + .dac_gain = 3,
> + .mix_gain = 8,
> + .rf_power = -3,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 0,
> + .dac_gain = 3,
> + .mix_gain = 9,
> + .rf_power = 0,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 0,
> + .dac_gain = 3,
> + .mix_gain = 12,
> + .rf_power = 3,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 0,
> + .dac_gain = 3,
> + .mix_gain = 13,
> + .rf_power = 4,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 1,
> + .dac_gain = 3,
> + .mix_gain = 8,
> + .rf_power = 6,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 1,
> + .dac_gain = 3,
> + .mix_gain = 9,
> + .rf_power = 9,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 1,
> + .dac_gain = 3,
> + .mix_gain = 10,
> + .rf_power = 10,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 1,
> + .dac_gain = 3,
> + .mix_gain = 11,
> + .rf_power = 12,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 1,
> + .dac_gain = 3,
> + .mix_gain = 12,
> + .rf_power = 13,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 1,
> + .dac_gain = 3,
> + .mix_gain = 13,
> + .rf_power = 14,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 1,
> + .dac_gain = 3,
> + .mix_gain = 15,
> + .rf_power = 16,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 2,
> + .dac_gain = 3,
> + .mix_gain = 10,
> + .rf_power = 19,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 2,
> + .dac_gain = 3,
> + .mix_gain = 11,
> + .rf_power = 21,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 2,
> + .dac_gain = 3,
> + .mix_gain = 12,
> + .rf_power = 22,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 2,
> + .dac_gain = 3,
> + .mix_gain = 13,
> + .rf_power = 24,
> + },
> + {
> + .dig_gain = 0,
> + .pa_gain = 2,
> + .dac_gain = 3,
> + .mix_gain = 14,
> + .rf_power = 25,
> + },
> +};
> +
> static const struct regmap_range_cfg sx1301_regmap_ranges[] = {
> {
> .name = "Pages",
> @@ -184,6 +299,34 @@ static int
Re: [v3 PATCH 1/2] mm: swap: check if swap backing device is congested or not
On Sat, 22 Dec 2018 05:40:19 +0800 Yang Shi wrote: > Swap readahead would read in a few pages regardless if the underlying > device is busy or not. It may incur long waiting time if the device is > congested, and it may also exacerbate the congestion. > > Use inode_read_congested() to check if the underlying device is busy or > not like what file page readahead does. Get inode from swap_info_struct. > Although we can add inode information in swap_address_space > (address_space->host), it may lead some unexpected side effect, i.e. > it may break mapping_cap_account_dirty(). Using inode from > swap_info_struct seems simple and good enough. > > Just does the check in vma_cluster_readahead() since > swap_vma_readahead() is just used for non-rotational device which > much less likely has congestion than traditional HDD. > > Although swap slots may be consecutive on swap partition, it still may be > fragmented on swap file. This check would help to reduce excessive stall > for such case. Some words about the observed effects of the patch would be more than appropriate!
WARNING in __might_sleep (2)
Hello, syzbot found the following crash on: HEAD commit:8fe28cb58bcb Linux 4.20 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16211a3b40 kernel config: https://syzkaller.appspot.com/x/.config?x=7d581260bae0899a dashboard link: https://syzkaller.appspot.com/bug?extid=c244af085a0159d22879 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1617cd8b40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11f5089b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c244af085a0159d22...@syzkaller.appspotmail.com audit: type=1800 audit(1545700018.193:29): pid=7508 uid=0 auid=4294967295 ses=4294967295 subj==unconfined op=collect_data cause=failed(directio) comm="startpar" name="rc.local" dev="sda1" ino=2432 res=0 [ cut here ] do not call blocking ops when !TASK_RUNNING; state=1 set at [<4df58f46>] n_hdlc_tty_read+0x301/0x7f0 drivers/tty/n_hdlc.c:589 WARNING: CPU: 0 PID: 7659 at kernel/sched/core.c:6099 __might_sleep+0x13d/0x190 kernel/sched/core.c:6094 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 7659 Comm: syz-executor111 Not tainted 4.20.0 #387 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113 panic+0x2ad/0x55c kernel/panic.c:188 __warn.cold.8+0x20/0x45 kernel/panic.c:540 report_bug+0x254/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973 RIP: 0010:__might_sleep+0x13d/0x190 kernel/sched/core.c:6094 Code: 65 48 8b 1c 25 40 ee 01 00 48 8d 7b 10 48 89 fe 48 c1 ee 03 80 3c 06 00 75 2b 48 8b 73 10 48 c7 c7 40 e0 2a 88 e8 43 27 f3 ff <0f> 0b e9 43 ff ff ff e8 f7 7c 6c 00 e9 26 ff ff ff e8 ed 7c 6c 00 RSP: 0018:8881b8db7948 EFLAGS: 00010286 RAX: RBX: 8881b8cae6c0 RCX: RDX: RSI: 8164e045 RDI: 0005 RBP: 8881b8db7978 R08: 8881b8cae6c0 R09: 0007 R10: R11: 8881b8cae6c0 R12: 8860b220 R13: 0019 R14: R15: 8881b8cae6c0 __might_fault+0xc6/0x1e0 mm/memory.c:4357 _copy_to_user+0x30/0x110 lib/usercopy.c:25 copy_to_user include/linux/uaccess.h:155 [inline] n_hdlc_tty_read+0x5c1/0x7f0 drivers/tty/n_hdlc.c:600 tty_read+0x194/0x2a0 drivers/tty/tty_io.c:866 __vfs_read+0x117/0x9b0 fs/read_write.c:416 vfs_read+0x17f/0x3c0 fs/read_write.c:452 ksys_read+0x101/0x260 fs/read_write.c:578 __do_sys_read fs/read_write.c:588 [inline] __se_sys_read fs/read_write.c:586 [inline] __x64_sys_read+0x73/0xb0 fs/read_write.c:586 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x440099 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffeeb4e9ec8 EFLAGS: 0207 ORIG_RAX: RAX: ffda RBX: 004002c8 RCX: 00440099 RDX: 0057 RSI: 2080 RDI: 0003 RBP: 006ca018 R08: 004002c8 R09: 004002c8 R10: 004002c8 R11: 0207 R12: 00401920 R13: 004019b0 R14: R15: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
KASAN: invalid-free in x25_asy_free
Hello, syzbot found the following crash on: HEAD commit:8fe28cb58bcb Linux 4.20 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13c11a3b40 kernel config: https://syzkaller.appspot.com/x/.config?x=7d581260bae0899a dashboard link: https://syzkaller.appspot.com/bug?extid=5e5e969e525129229052 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1574eeaf40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1417cd8b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+5e5e969e525129229...@syzkaller.appspotmail.com __alloc_pages include/linux/gfp.h:473 [inline] __alloc_pages_node include/linux/gfp.h:486 [inline] kmem_getpages mm/slab.c:1409 [inline] cache_grow_begin+0x91/0x8c0 mm/slab.c:2677 == cache_alloc_refill mm/slab.c:3044 [inline] cache_alloc mm/slab.c:3127 [inline] slab_alloc_node mm/slab.c:3322 [inline] kmem_cache_alloc_node_trace+0x670/0x740 mm/slab.c:3661 BUG: KASAN: double-free or invalid-free in x25_asy_free+0x37/0x140 drivers/net/wan/x25_asy.c:111 __do_kmalloc_node mm/slab.c:3683 [inline] __kmalloc_node+0x3c/0x70 mm/slab.c:3691 kmalloc_node include/linux/slab.h:589 [inline] kvmalloc_node+0x65/0xf0 mm/util.c:416 kvmalloc include/linux/mm.h:577 [inline] kvzalloc include/linux/mm.h:585 [inline] alloc_netdev_mqs+0x17b/0xfe0 net/core/dev.c:8949 x25_asy_alloc drivers/net/wan/x25_asy.c:83 [inline] x25_asy_open_tty+0x551/0x7e7 drivers/net/wan/x25_asy.c:556 tty_ldisc_open.isra.1+0x8b/0xe0 drivers/tty/tty_ldisc.c:453 tty_set_ldisc+0x2dc/0x6a0 drivers/tty/tty_ldisc.c:578 tiocsetd drivers/tty/tty_io.c:2321 [inline] tty_ioctl+0x39d/0x17d0 drivers/tty/tty_io.c:2581 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4410e9 Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 0b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc32511548 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: RCX: 004410e9 RDX: 2000 RSI: 5423 RDI: 0003 RBP: 7ffc32511560 R08: 0001 R09: R10: R11: 0246 R12: R13: 0004 R14: R15: CPU: 0 PID: 7925 Comm: syz-executor081 Not tainted 4.20.0 #387 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256 kasan_report_invalid_free+0x64/0xa0 mm/kasan/report.c:336 __kasan_slab_free+0x13a/0x150 mm/kasan/kasan.c:501 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xcf/0x230 mm/slab.c:3817 x25_asy_free+0x37/0x140 drivers/net/wan/x25_asy.c:111 x25_asy_open_tty+0x6ad/0x7e7 drivers/net/wan/x25_asy.c:572 tty_ldisc_open.isra.1+0x8b/0xe0 drivers/tty/tty_ldisc.c:453 tty_set_ldisc+0x2dc/0x6a0 drivers/tty/tty_ldisc.c:578 tiocsetd drivers/tty/tty_io.c:2321 [inline] tty_ioctl+0x39d/0x17d0 drivers/tty/tty_io.c:2581 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4410e9 Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 0b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00 kobject: 'queues' (1e78d271): kobject_uevent_env: filter function caused the event to drop! RSP: 002b:7ffc32511548 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: RCX: 004410e9 RDX: 2000 RSI: 5423 RDI: 0003 RBP: 7ffc32511560 R08: 0001 R09: R10: R11: 0246 R12: R13: 0004 R14: R15: kobject: 'rx-0' (b3577da5): kobject_add_internal: parent: 'queues', set: 'queues' Allocated by task 7925: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track
Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation
On Fri, 28 Dec 2018 at 23:16, Andreas Dilger wrot > On Dec 28, 2018, at 4:18 AM, Peter Maydell wrote: > > The problem is that there is no 32-bit API in some cases > > (unless I have misunderstood the kernel code) -- not all > > host architectures implement compat syscalls or allow them > > to be called from 64-bit processes or implement all the older > > syscall variants that had smaller offets. If there was a guaranteed > > "this syscall always exists and always gives me 32-bit offsets" > > we could use it. > > The "32bitapi" mount option would use 32-bit hash for seekdir > and telldir, regardless of what kernel API was used. That would > just set the FMODE_32BITHASH flag in the file->f_mode for all files. A mount option wouldn't be much use to QEMU -- we can't tell our users how to mount their filesystems, which they're often doing lots of other things with besides running QEMU. (Otherwise we could just tell them "don't use ext4", which would also solve the problem :-)) We need something we can use at the individual-syscall level. thanks -- PMM
RE: [PATCH V2 1/3] dt-bindings: mmc: tegra: Add pinctrl for pad drive strength config
Hi Rob,
>> Add pinctrl for 3V3 and 1V8 pad drive strength configuration for
>> Tegra210 sdmmc which has pad configuration registers in the pinmux
>> reigster domain.
>
> typo
>
>>
>> Signed-off-by: Sowjanya Komatineni
>> ---
>> Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt | 6
>> +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
>> b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
>> index 32b4b4e41923..2cecdc71d94c 100644
>> --- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
>> @@ -39,12 +39,16 @@ sdhci@c8000200 {
>> bus-width = <8>;
>> };
>>
>> -Optional properties for Tegra210 and Tegra186:
>> +Optional properties for Tegra210, Tegra186 and Tegra194:
>
>Adding Tegra194, but this patch concerns Tegra210...
Yes this is mainly part of Tegra210 Patch but pinctrls sdmmc-1v8 and sdmmc-3v3
also applies for Tegra194 and since it was not mentioned, added Tegra194 as
well.
Does adding Tegra194 in this should come as separate patch?
>
>> - pinctrl-names, pinctrl-0, pinctrl-1 : Specify pad voltage
>>configurations. Valid pinctrl-names are "sdmmc-3v3" and "sdmmc-1v8"
>>for controllers supporting multiple voltage levels. The order of names
>>should correspond to the pin configuration states in pinctrl-0 and
>>pinctrl-1.
>> +- pinctrl-names : "sdmmc-3v3-drv" and "sdmmc-1v8-drv" are applicable
>> +for
>
>These are in addition to the previous values?
Yes these are additional pinctrl states for pad drive settings which are in
pinmux
Domain and are applicable during calibration process.
>
>> + Tegra210 where pad config registers are in the pinmux register
>> + domain for pull-up-strength and pull-down-strength values
>> + configuration when using pads at 3V3 and 1V8 levels.
>> - nvidia,only-1-8-v : The presence of this property indicates that the
>>controller operates at a 1.8 V fixed I/O voltage.
>> - nvidia,pad-autocal-pull-up-offset-3v3,
>> --
>> 2.7.4
>>
Thanks & Regards,
sowjanya
Re: [PATCH 4/7] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
On Wed, Dec 19, 2018 at 03:11:02PM -0700, Lina Iyer wrote:
> SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO
> routed to the PDC as interrupts that can be used to wake the system up
> from deep low power modes and suspend.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Lina Iyer
> ---
> .../devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt| 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt
> index 665aadb5ea28..a522ca46667d 100644
> --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt
> @@ -29,6 +29,11 @@ SDM845 platform.
> Definition: must be 2. Specifying the pin number and flags, as defined
> in
>
> +- wakeup-parent:
> + Usage: optional
> + Value type:
> + Definition: A phandle to the wakeup interrupt controller for the SoC.
Is this really necessary? Is there more than one possible wakeup-parent
node?
> +
> - gpio-controller:
> Usage: required
> Value type:
> @@ -53,7 +58,6 @@ pin, a group, or a list of pins or groups. This
> configuration can include the
> mux function to select on those pin(s)/group(s), and various pin
> configuration
> parameters, such as pull-up, drive strength, etc.
>
> -
> PIN CONFIGURATION NODES:
>
> The name of each subnode is not important; all subnodes should be enumerated
> @@ -160,6 +164,7 @@ Example:
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + wakeup-parent = <>;
>
> qup9_active: qup9-active {
> mux {
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH RFC lora-next 1/4] net: lora: sx125x sx1301: correct style warnings
Hi Ben, Am 19.12.18 um 16:56 schrieb Ben Whitten: > Checkpatch highlights some style issues which need to be addressed. > > Signed-off-by: Ben Whitten > --- > drivers/net/lora/sx125x.c | 20 +-- > drivers/net/lora/sx1301.c | 52 ++- > drivers/net/lora/sx1301.h | 7 +++--- > 3 files changed, 45 insertions(+), 34 deletions(-) Thanks for splitting this off from the functional changes. This will need some more explanations and discussion. In particular the comment changes look wrong to me. Also please don't butcher code just because checkpatch.pl may warn about line length at this early stage. A good catch in there was the unsigned casts, which are no longer necessary since the regmap conversion, so we should just squash that into the earlier commits. Note that I used to run checkpatch.pl as git commit hook: http://blog.vmsplice.net/2011/03/how-to-automatically-run-checkpatchpl.html But since some git update that started to break git rebase -i in case of false positives (with rebase stopping and on trying to continue commits unintentionally getting squashed), so I deactivated it again and don't manually check each commit I stage anymore, in favor of slowly completing implementations to a working point. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 1/2] dt: bindings: lp5024: Introduce the lp5024 and lp5018 RGB driver
On Wed, Dec 19, 2018 at 10:26:25AM -0600, Dan Murphy wrote:
> Introduce the bindings for the Texas Instruments LP5024 and the LP5018
> RGB LED device driver. The LP5024/18 can control RGB LEDs individually
> or as part of a control bank group. These devices have the ability
> to adjust the mixing control for the RGB LEDs to obtain different colors
> independent of the overall brightness of the LED grouping.
>
> Datasheet:
> http://www.ti.com/lit/ds/symlink/lp5024.pdf
>
> Signed-off-by: Dan Murphy
> ---
> .../devicetree/bindings/leds/leds-lp5024.txt | 63 +++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-lp5024.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp5024.txt
> b/Documentation/devicetree/bindings/leds/leds-lp5024.txt
> new file mode 100644
> index ..9567aa6f7813
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-lp5024.txt
> @@ -0,0 +1,63 @@
> +* Texas Instruments - LP5024/18 RGB LED driver
> +
> +The LM3692x is an ultra-compact, highly efficient,
> +white-LED driver designed for LCD display backlighting.
Leftover copy-n-paste?
> +
> +The main difference between the LP5024 and L5018 is the number of
> +RGB LEDs they support. The LP5024 supports twenty four strings while the
> +LP5018 supports eighteen strings.
> +
> +Required properties:
> + - compatible:
> + "ti,lp5018"
> + "ti,lp5024"
> + - reg : I2C slave address
> + - #address-cells : 1
> + - #size-cells : 0
> +
> +Optional properties:
> + - enable-gpios : gpio pin to enable/disable the device.
> + - vled-supply : LED supply
> +
> +Required child properties:
> + - reg : Is the child node iteration.
> + - led-sources : LP5024 - 0 - 7
> + LP5018 - 0 - 5
> + Declares the LED string or strings that the child node
> + will control. If ti,control-bank is set then this
> + property will contain multiple LED IDs.
> +
> +Optional child properties:
> + - label : see Documentation/devicetree/bindings/leds/common.txt
> + - linux,default-trigger :
> +see Documentation/devicetree/bindings/leds/common.txt
> + - ti,control-bank : Indicates that the LED strings declared in the
> + led-sources property are grouped within a control
> + bank for brightness and mixing control.
> +
> +Example:
> +
> +led-controller@28 {
> + compatible = "ti,lp5024";
> + reg = <0x28>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
> + vled-supply = <>;
> +
> + led@0 {
> + reg = <0>;
> + led-sources = <1>;
> + };
> +
> + led@1 {
> + reg = <1>;
> + led-sources = <0 6>;
> + ti,control-bank;
> + };
> +
> +}
> +
> +For more product information please see the link below:
> +http://www.ti.com/lit/ds/symlink/lp5024.pdf
> --
> 2.20.0.rc2.7.g965798d1f2
>
Re: KASAN: use-after-free Read in filemap_fault
On Fri, Dec 28, 2018 at 01:09:38PM -0800, Andrew Morton wrote:
> On Fri, 28 Dec 2018 12:51:04 -0800 syzbot
> wrote:
>
> > Hello,
> >
> > syzbot found the following crash on:
>
> uh-oh. Josef, could you please take a look?
>
> : page = find_get_page(mapping, offset);
> : if (likely(page) && !(vmf->flags & FAULT_FLAG_TRIED)) {
> : /*
> : * We found the page, so try async readahead before
> : * waiting for the lock.
> : */
> : fpin = do_async_mmap_readahead(vmf, page);
> : } else if (!page) {
> : /* No page in the page cache at all */
> : fpin = do_sync_mmap_readahead(vmf);
> : count_vm_event(PGMAJFAULT);
> : count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
>
> vmf->vma has been freed at this point.
>
> : ret = VM_FAULT_MAJOR;
> : retry_find:
> : page = pagecache_get_page(mapping, offset,
> : FGP_CREAT|FGP_FOR_MMAP,
> : vmf->gfp_mask);
> : if (!page) {
> : if (fpin)
> : goto out_retry;
> : return vmf_error(-ENOMEM);
> : }
> : }
>
Here's a fixup for "filemap: drop the mmap_sem for all blocking operations".
do_sync_mmap_readahead() drops mmap_sem now, so by the time of
dereferencing vmf->vma for count_memcg_event_mm() the VMA can be gone.
diff --git a/mm/filemap.c b/mm/filemap.c
index 00a9315f45d4..65c85c47bdb1 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2554,10 +2554,10 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
fpin = do_async_mmap_readahead(vmf, page);
} else if (!page) {
/* No page in the page cache at all */
- fpin = do_sync_mmap_readahead(vmf);
count_vm_event(PGMAJFAULT);
count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
ret = VM_FAULT_MAJOR;
+ fpin = do_sync_mmap_readahead(vmf);
retry_find:
page = pagecache_get_page(mapping, offset,
FGP_CREAT|FGP_FOR_MMAP,
--
Kirill A. Shutemov
Re: [PATCH] bitmap: Add bitmap_valloc(), bitmap_vzalloc() and bitmap_vfree()
On Fri, 28 Dec 2018 00:18:29 +0800 Peng Wang wrote: > Introduce bitmap alloc/free helpers when contiguous > memory is not necessary. That's a large bitmap you have there. What code needs this?
Re: [PATCH] lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr
On Fri, 28 Dec 2018 09:48:34 +0100 Christoph Hellwig wrote: > On Fri, Dec 28, 2018 at 04:39:50PM +0800, Huang Shijie wrote: > > Follow the kernel conventions, rename addr_in_gen_pool to > > gen_pool_has_addr. > > Which convention? That symbols from subsystem foo should be called foo_*. Not uniformly observed by any means, but it is a thing. > The old name certainly looks more sensible to me. It does read better, but it's rather a standout in this case: q:/usr/src/25> grep EXPORT_SYMBOL lib/genalloc.c EXPORT_SYMBOL(gen_pool_create); EXPORT_SYMBOL(gen_pool_add_virt); EXPORT_SYMBOL(gen_pool_virt_to_phys); EXPORT_SYMBOL(gen_pool_destroy); EXPORT_SYMBOL(gen_pool_alloc); EXPORT_SYMBOL(gen_pool_alloc_algo); EXPORT_SYMBOL(gen_pool_dma_alloc); EXPORT_SYMBOL(gen_pool_free); EXPORT_SYMBOL(gen_pool_for_each_chunk); EXPORT_SYMBOL(addr_in_gen_pool); EXPORT_SYMBOL_GPL(gen_pool_avail); EXPORT_SYMBOL_GPL(gen_pool_size); EXPORT_SYMBOL(gen_pool_set_algo); EXPORT_SYMBOL(gen_pool_first_fit); EXPORT_SYMBOL(gen_pool_first_fit_align); EXPORT_SYMBOL(gen_pool_fixed_alloc); EXPORT_SYMBOL(gen_pool_first_fit_order_align); EXPORT_SYMBOL(gen_pool_best_fit); EXPORT_SYMBOL_GPL(gen_pool_get); EXPORT_SYMBOL(devm_gen_pool_create); EXPORT_SYMBOL_GPL(of_gen_pool_get);
Re: [PATCH V3] dt-bindings: timer: gpt: update binding doc
On Wed, Dec 19, 2018 at 07:09:10AM +, Anson Huang wrote:
> The i.MX GPT timer driver binding doc is out of date,
> update it according to current GPT timer driver.
>
> Signed-off-by: Anson Huang
> ---
> .../devicetree/bindings/timer/fsl,imxgpt.txt | 35
> ++
> 1 file changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> index 9809b11..a7f23a6 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> +++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> @@ -2,17 +2,40 @@ Freescale i.MX General Purpose Timer (GPT)
>
> Required properties:
>
> -- compatible : should be "fsl,-gpt"
> -- reg : Specifies base physical address and size of the registers.
> -- interrupts : A list of 4 interrupts; one per timer channel.
> -- clocks : The clocks provided by the SoC to drive the timer.
> +- compatible : should be one of following:
> +
> + should be "fsl,imx1-gpt" for i.MX1;
> +
> + should be one of following for i.MX21/i.MX27:
> + - "fsl,imx21-gpt",
> + - "fsl,imx27-gpt",
What this says and your example still don't match. I think you want:
- "fsl,imx21-gpt"
- "fsl,imx27-gpt", "fsl,imx21-gpt"
> +
> + should be one of following for i.MX31/i.MX25/i.MX50/i.MX51/i.MX53/i.MX6Q:
> + - "fsl,imx31-gpt",
> + - "fsl,imx25-gpt",
> + - "fsl,imx50-gpt",
> + - "fsl,imx51-gpt",
> + - "fsl,imx53-gpt",
> + - "fsl,imx6q-gpt",
I'm sure some of these are backwards compatible.
> +
> + should be one of following for i.MX6DL/i.MX6SL/i.MX6SX:
> + - "fsl,imx6dl-gpt",
> + - "fsl,imx6sl-gpt",
> + - "fsl,imx6sx-gpt".
> +
> +- reg : specifies base physical address and size of the registers.
> +- interrupts : should be the gpt interrupt.
> +- clocks : the clocks provided by the SoC to drive the timer, must contain
> + an entry for each entry in clock-names.
> +- clock-names : must include "ipg" entry first, then "per" entry.
>
> Example:
>
> gpt1: timer@10003000 {
> - compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
> + compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
> reg = <0x10003000 0x1000>;
> interrupts = <26>;
> - clocks = < 46>, < 61>;
> + clocks = < IMX27_CLK_GPT1_IPG_GATE>,
> + < IMX27_CLK_PER1_GATE>;
> clock-names = "ipg", "per";
> };
> --
> 2.7.4
>
Re: [PATCH v5 RESEND] signal: add pidfd_send_signal() syscall
On Fri, Dec 28, 2018 at 03:20:12PM -0800, Andrew Morton wrote: > On Fri, 28 Dec 2018 23:48:53 +0100 Christian Brauner > wrote: > > > The kill() syscall operates on process identifiers (pid). After a process > > has exited its pid can be reused by another process. If a caller sends a > > signal to a reused pid it will end up signaling the wrong process. This > > issue has often surfaced and there has been a push to address this problem > > [1]. > > > > This patch uses file descriptors (fd) from proc/ as stable handles on > > struct pid. Even if a pid is recycled the handle will not change. The fd > > can be used to send signals to the process it refers to. > > Thus, the new syscall pidfd_send_signal() is introduced to solve this > > problem. Instead of pids it operates on process fds (pidfd). So most of the questions you ask have been extensively discussed in prior threads. All of them have links above in the long commit message. > > I can't see a description of what happens when the target process has > exited. Is the task_struct pinned by the fd? Does the entire procfs A reference to struct pid is kept. struct pid - as far as I understand - was created exactly for the reason to not require to pin struct task_struct. This is also noted in the comments to struct pid: https://elixir.bootlin.com/linux/v4.20-rc1/source/include/linux/pid.h#L16 > directory remain visible? Just one entry within it? Does the pid The same thing that happens when you currently keep an fd to /proc/ open. > remain reserved? Do attempts to signal that fd return errors? The pid does not remain reserved. Which leads back to your question about what happens when you try to signal a process that has exited: you get ESRCH. > etcetera. These behaviors should be described in the changelog and > manipulate please. I can add those questions to the changelog too. > > The code in signal.c appears to be compiled in even when > CONFIG_PROC_FS=y. Can we add the appropriate ifdefs and an entry in > sys_ni.c? Without having looked super close at this from the top of my head I'd say, yes we can. > > A selftest in toole/testing/selftests would be nice. And it will be > helpful to architecture maintainers as they wire this up. I can extend the sample program in the commit message to a selftest. > > The feature doesn't have its own Kconfig setting. Perhaps it should? > It should presumably depend on PROC_FS. Not sure why we should do this. > > I must say that I dislike the linkage to procfs. procfs is a > high-level thing which is manipulated using syscalls. To turn around > and make a syscall dependent upon the presence of procfs seems just ... > wrong. Is there a cleaner way of obtaining the fd? Another syscall > perhaps. We may do something like this in the future. There's another syscall lined up at some point translate_pid() which we may extend to also give back an fd to a process. For now the open() on /proc/ is the cleanest way of doing this. > > This fd-for-a-process sounds like a handy thing and people may well > think up other uses for it in the future, probably unrelated to > signals. Are the code and the interface designed to permit such future > applications? I guess "no" - it presently assumes that anything which This too has been discussed in prior threads linked in the commit message. Yes, it does permit of such extension and we have already publicly discussed future extensions (e.g. wait maybe a new clone syscall). > is written to that fd is a signal. Perhaps there should be a tag at > the start of the message (which is what it is) which identifies the > message's type? > > Now I think about it, why a new syscall? This thing is looking rather > like an ioctl? Again, we have had a lengthy discussion about this and by now we all agree that a dedicated syscall makes more sense than an ioctl() for security reasons, because processes are a core-kernel concept, and we intend to extend this api with syscalls in the future (e.g. wait etc. also discussed in prior threads linked in here). There's also a summary article on lwn about parts of this (https://lwn.net/Articles/773459/). Thanks! Christian
