* Re: [PATCH 0/8] net: Manufacturer names and spelling fixes
From: David Miller @ 2019-08-01 17:46 UTC (permalink / raw)
To: geert+renesas; +Cc: netdev, linux-kernel
In-Reply-To: <20190731132216.17194-1-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Wed, 31 Jul 2019 15:22:08 +0200
> This is a set of fixes for (some blatantly) wrong manufacturer names
> and various spelling issues, mostly in Kconfig help texts.
Series applied, thank you Geert.
^ permalink raw reply
* Re: [PATCH] net: sctp: Rename fallthrough label to unhandled
From: Joe Perches @ 2019-08-01 17:42 UTC (permalink / raw)
To: Neil Horman
Cc: Vlad Yasevich, Marcelo Ricardo Leitner, David S. Miller,
linux-sctp, netdev, linux-kernel
In-Reply-To: <20190801105051.GA11487@hmswarspite.think-freely.org>
On Thu, 2019-08-01 at 06:50 -0400, Neil Horman wrote:
> On Wed, Jul 31, 2019 at 03:23:46PM -0700, Joe Perches wrote:
[]
> You can say that if you want, but you made the point that your think the macro
> as you have written is more readable. You example illustrates though that /*
> fallthrough */ is a pretty common comment, and not prefixing it makes it look
> like someone didn't add a comment that they meant to. The __ prefix is standard
> practice for defining macros to attributes (212 instances of it by my count). I
> don't mind rewriting the goto labels at all, but I think consistency is
> valuable.
Hey Neil.
Perhaps you want to make this argument on the RFC patch thread
that introduces the fallthrough pseudo-keyword.
https://lore.kernel.org/patchwork/patch/1108577/
^ permalink raw reply
* Re: [net-next 00/16][pull request] 100GbE Intel Wired LAN Driver Updates 2019-07-31
From: David Miller @ 2019-08-01 17:42 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190731204147.8582-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 31 Jul 2019 13:41:31 -0700
> This series contains updates to ice driver only.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH bpf-next v10 06/10] bpf,landlock: Add a new map type: inode
From: Alexei Starovoitov @ 2019-08-01 17:35 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Mickaël Salaün, LKML, Alexander Viro,
Alexei Starovoitov, Andrew Morton, Andy Lutomirski,
Arnaldo Carvalho de Melo, Casey Schaufler, Daniel Borkmann,
David Drysdale, David S . Miller, Eric W . Biederman,
James Morris, Jann Horn, John Johansen, Jonathan Corbet,
Kees Cook, Michael Kerrisk, Paul Moore, Sargun Dhillon,
Serge E . Hallyn, Shuah Khan, Stephen Smalley, Tejun Heo,
Tetsuo Handa, Thomas Graf, Tycho Andersen, Will Drewry,
Kernel Hardening, Linux API, Linux-Fsdevel, LSM List,
Network Development
In-Reply-To: <59e8fab9-34df-0ebe-ca6b-8b34bf582b75@ssi.gouv.fr>
On Wed, Jul 31, 2019 at 09:11:10PM +0200, Mickaël Salaün wrote:
>
>
> On 31/07/2019 20:58, Alexei Starovoitov wrote:
> > On Wed, Jul 31, 2019 at 11:46 AM Mickaël Salaün
> > <mickael.salaun@ssi.gouv.fr> wrote:
> >>>> + for (i = 0; i < htab->n_buckets; i++) {
> >>>> + head = select_bucket(htab, i);
> >>>> + hlist_nulls_for_each_entry_safe(l, n, head, hash_node) {
> >>>> + landlock_inode_remove_map(*((struct inode **)l->key), map);
> >>>> + }
> >>>> + }
> >>>> + htab_map_free(map);
> >>>> +}
> >>>
> >>> user space can delete the map.
> >>> that will trigger inode_htab_map_free() which will call
> >>> landlock_inode_remove_map().
> >>> which will simply itereate the list and delete from the list.
> >>
> >> landlock_inode_remove_map() removes the reference to the map (being
> >> freed) from the inode (with an RCU lock).
> >
> > I'm going to ignore everything else for now and focus only on this bit,
> > since it's fundamental issue to address before this discussion can
> > go any further.
> > rcu_lock is not a spin_lock. I'm pretty sure you know this.
> > But you're arguing that it's somehow protecting from the race
> > I mentioned above?
> >
>
> I was just clarifying your comment to avoid misunderstanding about what
> is being removed.
>
> As said in the full response, there is currently a race but, if I add a
> bpf_map_inc() call when the map is referenced by inode->security, then I
> don't see how a race could occur because such added map could only be
> freed in a security_inode_free() (as long as it retains a reference to
> this inode).
then it will be a cycle and a map will never be deleted?
closing map_fd should delete a map. It cannot be alive if it's not
pinned in bpffs, there are no FDs that are holding it, and no progs using it.
So the map deletion will iterate over inodes that belong to this map.
In parallel security_inode_free() will be called that will iterate
over its link list that contains elements from different maps.
So the same link list is modified by two cpus.
Where is a lock that protects from concurrent links list manipulations?
> Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.
Please get rid of this. It's absolutely not appropriate on public mailing list.
Next time I'd have to ignore emails that contain such disclaimers.
^ permalink raw reply
* Re: [PATCH net-next 00/12] net: hns3: some code optimizations & bugfixes & features
From: David Miller @ 2019-08-01 17:32 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <1564631745-36733-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Thu, 1 Aug 2019 11:55:33 +0800
> This patch-set includes code optimizations, bugfixes and features for
> the HNS3 ethernet controller driver.
These look good, series applied, thanks.
^ permalink raw reply
* Re: [PATCH v1 2/2] net: npcm: add NPCM7xx EMC 10/100 Ethernet driver
From: Willem de Bruijn @ 2019-08-01 17:25 UTC (permalink / raw)
To: Avi Fishman
Cc: Patrick Venture, Nancy Yuen, benjaminfair, David Miller, robh+dt,
mark.rutland, Greg Kroah-Hartman, tmaimon77, tali.perry1, openbmc,
Network Development, devicetree, linux-kernel, tglx
In-Reply-To: <20190801072611.27935-3-avifishman70@gmail.com>
On Thu, Aug 1, 2019 at 3:28 AM Avi Fishman <avifishman70@gmail.com> wrote:
>
> EMC Ethernet Media Access Controller supports 10/100 Mbps and
> RMII.
> This driver has been working on Nuvoton BMC NPCM7xx.
>
> Signed-off-by: Avi Fishman <avifishman70@gmail.com>
> +/* global setting for driver */
> +#define RX_QUEUE_LEN 128
> +#define TX_QUEUE_LEN 64
> +#define MAX_RBUFF_SZ 0x600
> +#define MAX_TBUFF_SZ 0x600
> +#define TX_TIMEOUT 50
> +#define DELAY 1000
> +#define CAM0 0x0
> +#define RX_POLL_SIZE 16
> +
> +#ifdef CONFIG_VLAN_8021Q
> +#define IS_VLAN 1
> +#else
> +#define IS_VLAN 0
> +#endif
> +
> +#define MAX_PACKET_SIZE (1514 + (IS_VLAN * 4))
1514 -> ETH_FRAME_LEN
4 -> VLAN_HLEN
Does this device support stacked VLAN?
Is this really the device maximum?
> +#define MAX_PACKET_SIZE_W_CRC (MAX_PACKET_SIZE + 4) /* 1518 */
4 -> ETH_FCS_LEN
> +#if defined CONFIG_NPCM7XX_EMC_ETH_DEBUG || defined CONFIG_DEBUG_FS
> +#define REG_PRINT(reg_name) {t = scnprintf(next, size, "%-10s = %08X\n", \
> + #reg_name, readl(ether->reg + (reg_name))); size -= t; next += t; }
> +#define DUMP_PRINT(f, x...) {t = scnprintf(next, size, f, ## x); size -= t; \
> + next += t; }
> +
> +static int npcm7xx_info_dump(char *buf, int count, struct net_device *netdev)
> +{
> + struct npcm7xx_ether *ether = netdev_priv(netdev);
> + struct npcm7xx_txbd *txbd;
> + struct npcm7xx_rxbd *rxbd;
> + unsigned long flags;
> + unsigned int i, cur, txd_offset, rxd_offset;
> + char *next = buf;
> + unsigned int size = count;
> + int t;
> + int is_locked = spin_is_locked(ðer->lock);
> +
> + if (!is_locked)
> + spin_lock_irqsave(ðer->lock, flags);
> +
> + /* ------basic driver information ---- */
> + DUMP_PRINT("NPCM7XX EMC %s driver version: %s\n", netdev->name,
> + DRV_MODULE_VERSION);
> +
> + REG_PRINT(REG_CAMCMR);
> + REG_PRINT(REG_CAMEN);
> + REG_PRINT(REG_CAMM_BASE);
> + REG_PRINT(REG_CAML_BASE);
> + REG_PRINT(REG_TXDLSA);
> + REG_PRINT(REG_RXDLSA);
> + REG_PRINT(REG_MCMDR);
> + REG_PRINT(REG_MIID);
> + REG_PRINT(REG_MIIDA);
> + REG_PRINT(REG_FFTCR);
> + REG_PRINT(REG_TSDR);
> + REG_PRINT(REG_RSDR);
> + REG_PRINT(REG_DMARFC);
> + REG_PRINT(REG_MIEN);
> + REG_PRINT(REG_MISTA);
> + REG_PRINT(REG_MGSTA);
> + REG_PRINT(REG_MPCNT);
> + writel(0x7FFF, (ether->reg + REG_MPCNT));
> + REG_PRINT(REG_MRPC);
> + REG_PRINT(REG_MRPCC);
> + REG_PRINT(REG_MREPC);
> + REG_PRINT(REG_DMARFS);
> + REG_PRINT(REG_CTXDSA);
> + REG_PRINT(REG_CTXBSA);
> + REG_PRINT(REG_CRXDSA);
> + REG_PRINT(REG_CRXBSA);
> + REG_PRINT(REG_RXFSM);
> + REG_PRINT(REG_TXFSM);
> + REG_PRINT(REG_FSM0);
> + REG_PRINT(REG_FSM1);
> + REG_PRINT(REG_DCR);
> + REG_PRINT(REG_DMMIR);
> + REG_PRINT(REG_BISTR);
> + DUMP_PRINT("\n");
> +
> + DUMP_PRINT("netif_queue %s\n\n", netif_queue_stopped(netdev) ?
> + "Stopped" : "Running");
> + if (ether->rdesc)
> + DUMP_PRINT("napi is %s\n\n", test_bit(NAPI_STATE_SCHED,
> + ðer->napi.state) ?
> + "scheduled" :
> + "not scheduled");
> +
> + txd_offset = (readl((ether->reg + REG_CTXDSA)) -
> + readl((ether->reg + REG_TXDLSA))) /
> + sizeof(struct npcm7xx_txbd);
> + DUMP_PRINT("TXD offset %6d\n", txd_offset);
> + DUMP_PRINT("cur_tx %6d\n", ether->cur_tx);
> + DUMP_PRINT("finish_tx %6d\n", ether->finish_tx);
> + DUMP_PRINT("pending_tx %6d\n", ether->pending_tx);
> + /* debug counters */
> + DUMP_PRINT("tx_tdu %6d\n", ether->tx_tdu);
> + ether->tx_tdu = 0;
> + DUMP_PRINT("tx_tdu_i %6d\n", ether->tx_tdu_i);
> + ether->tx_tdu_i = 0;
> + DUMP_PRINT("tx_cp_i %6d\n", ether->tx_cp_i);
> + ether->tx_cp_i = 0;
> + DUMP_PRINT("tx_int_count %6d\n", ether->tx_int_count);
> + ether->tx_int_count = 0;
> + DUMP_PRINT("count_xmit tx %6d\n", ether->count_xmit);
> + ether->count_xmit = 0;
> + DUMP_PRINT("count_finish %6d\n", ether->count_finish);
> + ether->count_finish = 0;
> + DUMP_PRINT("\n");
> +
> + rxd_offset = (readl((ether->reg + REG_CRXDSA)) -
> + readl((ether->reg + REG_RXDLSA)))
> + / sizeof(struct npcm7xx_txbd);
> + DUMP_PRINT("RXD offset %6d\n", rxd_offset);
> + DUMP_PRINT("cur_rx %6d\n", ether->cur_rx);
> + DUMP_PRINT("rx_err %6d\n", ether->rx_err);
> + ether->rx_err = 0;
> + DUMP_PRINT("rx_berr %6d\n", ether->rx_berr);
> + ether->rx_berr = 0;
> + DUMP_PRINT("rx_stuck %6d\n", ether->rx_stuck);
> + ether->rx_stuck = 0;
> + DUMP_PRINT("rdu %6d\n", ether->rdu);
> + ether->rdu = 0;
> + DUMP_PRINT("rxov rx %6d\n", ether->rxov);
> + ether->rxov = 0;
> + /* debug counters */
> + DUMP_PRINT("rx_int_count %6d\n", ether->rx_int_count);
> + ether->rx_int_count = 0;
> + DUMP_PRINT("rx_err_count %6d\n", ether->rx_err_count);
> + ether->rx_err_count = 0;
Basic counters like tx_packets and rx_errors are probably better
exported regardless of debug level as net_device_stats. And then don't
need to be copied in debug output.
Less standard counters like tx interrupt count are probably better
candidates for ethtool -S.
> +#ifdef CONFIG_NPCM7XX_EMC_ETH_DEBUG
> +static void npcm7xx_info_print(struct net_device *netdev)
> +{
> + char *emc_dump_buf;
> + int count;
> + struct npcm7xx_ether *ether;
> + struct platform_device *pdev;
> + char c;
> + char *tmp_buf;
> + const size_t print_size = 5 * PAGE_SIZE;
> +
> + ether = netdev_priv(netdev);
> + pdev = ether->pdev;
> +
> + emc_dump_buf = kmalloc(print_size, GFP_KERNEL);
> + if (!emc_dump_buf)
> + return;
> +
> + tmp_buf = emc_dump_buf;
> + count = npcm7xx_info_dump(emc_dump_buf, print_size, netdev);
> + while (count > 512) {
> + c = tmp_buf[512];
> + tmp_buf[512] = 0;
> + dev_info(&pdev->dev, "%s", tmp_buf);
> + tmp_buf += 512;
> + tmp_buf[0] = c;
> + count -= 512;
Missing closing parenthesis.
Also, why this buffering to printk?
> +static void npcm7xx_write_cam(struct net_device *netdev,
> + unsigned int x, unsigned char *pval)
> +{
> + struct npcm7xx_ether *ether = netdev_priv(netdev);
> + __le32 msw, lsw;
> +
> + msw = (pval[0] << 24) | (pval[1] << 16) | (pval[2] << 8) | pval[3];
> +
> + lsw = (pval[4] << 24) | (pval[5] << 16);
Does __le32 plus this explicit shifting define host endianness? Better
to keep independent?
> +
> + writel(lsw, (ether->reg + REG_CAML_BASE) + x * CAM_ENTRY_SIZE);
> + writel(msw, (ether->reg + REG_CAMM_BASE) + x * CAM_ENTRY_SIZE);
> + dev_dbg(ðer->pdev->dev,
> + "REG_CAML_BASE = 0x%08X REG_CAMM_BASE = 0x%08X", lsw, msw);
> +}
> +
> +static struct sk_buff *get_new_skb(struct net_device *netdev, u32 i)
> +{
> + __le32 buffer;
> + struct npcm7xx_ether *ether = netdev_priv(netdev);
> + struct sk_buff *skb = netdev_alloc_skb(netdev,
> + roundup(MAX_PACKET_SIZE_W_CRC, 4));
> +
> + if (unlikely(!skb)) {
> + if (net_ratelimit())
> + netdev_warn(netdev, "failed to allocate rx skb\n");
can use net_warn_ratelimited (here and elsewhere)
> + buffer = ether->rx_scratch_dma;
> + } else {
> + /* Do not unmark the following skb_reserve() Receive Buffer
> + * Starting Address must be aligned to 4 bytes and the following
> + * line if unmarked will make it align to 2 and this likely will
> + * hult the RX and crash the linux
halt?
> + * skb_reserve(skb, NET_IP_ALIGN);
> + */
> + skb->dev = netdev;
> + buffer = dma_map_single(&netdev->dev,
> + skb->data,
> + roundup(MAX_PACKET_SIZE_W_CRC, 4),
> + DMA_FROM_DEVICE);
> + if (unlikely(dma_mapping_error(&netdev->dev, buffer))) {
> + if (net_ratelimit())
> + netdev_err(netdev, "failed to map rx page\n");
> + dev_kfree_skb_any(skb);
> + buffer = ether->rx_scratch_dma;
> + skb = NULL;
> + }
> + }
> + ether->rx_skb[i] = skb;
> + ether->rdesc[i].buffer = buffer;
> +
> + return skb;
> +}
> +
> +static int npcm7xx_ether_close(struct net_device *netdev)
> +{
> + struct npcm7xx_ether *ether = netdev_priv(netdev);
> +
> + npcm7xx_return_default_idle(netdev);
> +
> + if (ether->phy_dev)
> + phy_stop(ether->phy_dev);
> + else if (ether->use_ncsi)
> + ncsi_stop_dev(ether->ncsidev);
> +
> + msleep(20);
> +
> + free_irq(ether->txirq, netdev);
> + free_irq(ether->rxirq, netdev);
> +
> + netif_stop_queue(netdev);
> + napi_disable(ðer->napi);
Cleanup state in reverse of allocation.
> +static int npcm7xx_ether_start_xmit(struct sk_buff *skb, struct net_device *netdev)
> +{
> + struct npcm7xx_ether *ether = netdev_priv(netdev);
> + struct npcm7xx_txbd *txbd;
> + unsigned long flags;
> +
> + ether->count_xmit++;
> +
> + /* Insert new buffer */
> + txbd = (ether->tdesc + ether->cur_tx);
> + txbd->buffer = dma_map_single(&netdev->dev, skb->data, skb->len,
> + DMA_TO_DEVICE);
> + ether->tx_skb[ether->cur_tx] = skb;
> + if (skb->len > MAX_PACKET_SIZE)
> + dev_err(ðer->pdev->dev,
> + "skb->len (= %d) > MAX_PACKET_SIZE (= %d)\n",
> + skb->len, MAX_PACKET_SIZE);
> + txbd->sl = skb->len > MAX_PACKET_SIZE ? MAX_PACKET_SIZE : skb->len;
Check for errors before mapping to device, and drop packet? Probably
don't want to output truncated packets.
Also rate limit such messages.
> + dma_wmb();
> +
> + txbd->mode = TX_OWN_DMA | PADDINGMODE | CRCMODE;
> +
> + /* make sure that data is in memory before we trigger TX */
> + wmb();
> +
> + /* trigger TX */
> + writel(ENSTART, (ether->reg + REG_TSDR));
> +
> + if (++ether->cur_tx >= TX_QUEUE_LEN)
> + ether->cur_tx = 0;
> +
> + spin_lock_irqsave(ðer->lock, flags);
> + ether->pending_tx++;
> +
> + /* sometimes we miss the tx interrupt due to HW issue, so NAPI will not
> + * clean the pending tx, so we clean it also here
> + */
> + npcm7xx_clean_tx(netdev, true);
> +
> + if (ether->pending_tx >= TX_QUEUE_LEN - 1) {
> + __le32 reg_mien;
> + unsigned int index_to_wake = ether->cur_tx +
> + ((TX_QUEUE_LEN * 3) / 4);
> +
> + if (index_to_wake >= TX_QUEUE_LEN)
> + index_to_wake -= TX_QUEUE_LEN;
> +
> + txbd = (ether->tdesc + index_to_wake);
> + txbd->mode = TX_OWN_DMA | PADDINGMODE | CRCMODE | MACTXINTEN;
> +
> + /* make sure that data is in memory before we trigger TX */
> + wmb();
> +
> + /* Clear TDU interrupt */
> + writel(MISTA_TDU, (ether->reg + REG_MISTA));
> +
> + /* due to HW issue somtimes, we miss the TX interrupt we just
somtimes -> sometimes
> + * set (MACTXINTEN), so we also set TDU for Transmit
> + * Descriptor Unavailable interrupt
> + */
> + reg_mien = readl((ether->reg + REG_MIEN));
> + if (reg_mien != 0)
> + /* Enable TDU interrupt */
> + writel(reg_mien | ENTDU, (ether->reg + REG_MIEN));
> +
> + ether->tx_tdu++;
> + netif_stop_queue(netdev);
> + }
> +
> + spin_unlock_irqrestore(ðer->lock, flags);
> +
> + return 0;
> +}
> +
> +static irqreturn_t npcm7xx_tx_interrupt(int irq, void *dev_id)
> +{
> + struct npcm7xx_ether *ether;
> + struct platform_device *pdev;
> + struct net_device *netdev;
> + __le32 status;
> + unsigned long flags;
> +
> + netdev = dev_id;
> + ether = netdev_priv(netdev);
> + pdev = ether->pdev;
> +
> + npcm7xx_get_and_clear_int(netdev, &status, 0xFFFF0000);
> +
> + ether->tx_int_count++;
> +
> + if (status & MISTA_EXDEF)
> + dev_err(&pdev->dev, "emc defer exceed interrupt status=0x%08X\n"
> + , status);
> + else if (status & MISTA_TXBERR) {
> + dev_err(&pdev->dev, "emc bus error interrupt status=0x%08X\n",
> + status);
> +#ifdef CONFIG_NPCM7XX_EMC_ETH_DEBUG
> + npcm7xx_info_print(netdev);
> +#endif
> + spin_lock_irqsave(ðer->lock, flags);
irqsave in hard interrupt context?
> + writel(0, (ether->reg + REG_MIEN)); /* disable any interrupt */
> + spin_unlock_irqrestore(ðer->lock, flags);
> + ether->need_reset = 1;
> + } else if (status & ~(MISTA_TXINTR | MISTA_TXCP | MISTA_TDU))
> + dev_err(&pdev->dev, "emc other error interrupt status=0x%08X\n",
> + status);
> +
> + /* if we got MISTA_TXCP | MISTA_TDU remove those interrupt and call napi */
The goal of napi is to keep interrupts disabled until napi completes.
> + if (status & (MISTA_TXCP | MISTA_TDU) &
> + readl((ether->reg + REG_MIEN))) {
> + __le32 reg_mien;
> +
> + spin_lock_irqsave(ðer->lock, flags);
> + reg_mien = readl((ether->reg + REG_MIEN));
> + if (reg_mien & ENTDU)
> + /* Disable TDU interrupt */
> + writel(reg_mien & (~ENTDU), (ether->reg + REG_MIEN));
> +
> + spin_unlock_irqrestore(ðer->lock, flags);
> +
> + if (status & MISTA_TXCP)
> + ether->tx_cp_i++;
> + if (status & MISTA_TDU)
> + ether->tx_tdu_i++;
> + } else {
> + dev_dbg(&pdev->dev, "status=0x%08X\n", status);
> + }
> +
> + napi_schedule(ðer->napi);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t npcm7xx_rx_interrupt(int irq, void *dev_id)
> +{
> + struct net_device *netdev = (struct net_device *)dev_id;
> + struct npcm7xx_ether *ether = netdev_priv(netdev);
> + struct platform_device *pdev = ether->pdev;
> + __le32 status;
> + unsigned long flags;
> + unsigned int any_err = 0;
> + __le32 rxfsm;
> +
> + npcm7xx_get_and_clear_int(netdev, &status, 0xFFFF);
Same here
> +static int npcm7xx_poll(struct napi_struct *napi, int budget)
> +{
> + struct npcm7xx_ether *ether =
> + container_of(napi, struct npcm7xx_ether, napi);
> + struct npcm7xx_rxbd *rxbd;
> + struct net_device *netdev = ether->netdev;
> + struct platform_device *pdev = ether->pdev;
> + struct sk_buff *s;
> + unsigned int length;
> + __le32 status;
> + unsigned long flags;
> + int rx_cnt = 0;
> + int complete = 0;
> + unsigned int rx_offset = (readl((ether->reg + REG_CRXDSA)) -
> + ether->start_rx_ptr) /
> + sizeof(struct npcm7xx_txbd);
> + unsigned int local_count = (rx_offset >= ether->cur_rx) ?
> + rx_offset - ether->cur_rx : rx_offset +
> + RX_QUEUE_LEN - ether->cur_rx;
> +
> + if (local_count > ether->max_waiting_rx)
> + ether->max_waiting_rx = local_count;
> +
> + if (local_count > (4 * RX_POLL_SIZE))
> + /* we are porbably in a storm of short packets and we don't
porbably - probably
> + * want to get into RDU since short packets in RDU cause
> + * many RXOV which may cause EMC halt, so we filter out all
> + * coming packets
> + */
> + writel(0, (ether->reg + REG_CAMCMR));
> +
> + if (local_count <= budget)
> + /* we can restore accepting of packets */
> + writel(ether->camcmr, (ether->reg + REG_CAMCMR));
> +
> + spin_lock_irqsave(ðer->lock, flags);
> + npcm7xx_clean_tx(netdev, false);
> + spin_unlock_irqrestore(ðer->lock, flags);
> +
> + rxbd = (ether->rdesc + ether->cur_rx);
> +
> + while (rx_cnt < budget) {
> + status = rxbd->sl;
> + if ((status & RX_OWN_DMA) == RX_OWN_DMA) {
> + complete = 1;
> + break;
> + }
> + /* for debug puposes we save the previous value */
puposes -> purposes
> + rxbd->reserved = status;
> + s = ether->rx_skb[ether->cur_rx];
> + length = status & 0xFFFF;
> +
> + /* If VLAN is not supporte RXDS_PTLE (packet too long) is also
supporte -> supported (stopping pointing out typos after this).
> +static const struct net_device_ops npcm7xx_ether_netdev_ops = {
> + .ndo_open = npcm7xx_ether_open,
> + .ndo_stop = npcm7xx_ether_close,
> + .ndo_start_xmit = npcm7xx_ether_start_xmit,
> + .ndo_get_stats = npcm7xx_ether_stats,
> + .ndo_set_rx_mode = npcm7xx_ether_set_rx_mode,
> + .ndo_set_mac_address = npcm7xx_set_mac_address,
> + .ndo_do_ioctl = npcm7xx_ether_ioctl,
> + .ndo_validate_addr = eth_validate_addr,
> + .ndo_change_mtu = eth_change_mtu,
This is marked as deprecated. Also in light of the hardcoded
MAX_PACKET_SIZE, probably want to set dev->max_mtu.
> +static int npcm7xx_ether_probe(struct platform_device *pdev)
> +{
> + struct npcm7xx_ether *ether;
> + struct net_device *netdev;
> + int error;
> +
> + struct clk *emc_clk = NULL;
> + struct device_node *np = pdev->dev.of_node;
> +
> + pdev->id = of_alias_get_id(np, "ethernet");
> + if (pdev->id < 0)
> + pdev->id = 0;
> +
> + emc_clk = devm_clk_get(&pdev->dev, NULL);
> +
> + if (IS_ERR(emc_clk))
> + return PTR_ERR(emc_clk);
> +
> + /* Enable Clock */
> + clk_prepare_enable(emc_clk);
> +
> + error = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> + if (error)
> + return -ENODEV;
> +
> + netdev = alloc_etherdev(sizeof(struct npcm7xx_ether));
> + if (!netdev)
> + return -ENOMEM;
> +
> + ether = netdev_priv(netdev);
> +
> + ether->reset = devm_reset_control_get(&pdev->dev, NULL);
> + if (IS_ERR(ether->reset))
> + return PTR_ERR(ether->reset);
Memory leak on error path
Also missing netif_napi_del in npcm7xx_ether_remove?
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: mt7530: Convert to PHYLINK API
From: David Miller @ 2019-08-01 17:22 UTC (permalink / raw)
To: opensource
Cc: netdev, frank-w, sean.wang, f.fainelli, matthias.bgg, andrew,
vivien.didelot, john, linux-mediatek, linux-mips, robh+dt,
devicetree, linux
In-Reply-To: <20190801172104.Horde.Cuwt4jywUX_mcO9-n8QpWTN@www.vdorst.com>
From: René van Dorst <opensource@vdorst.com>
Date: Thu, 01 Aug 2019 17:21:04 +0000
> Quoting Russell King - ARM Linux admin <linux@armlinux.org.uk>:
>
>> Hi,
>>
>> Just a couple of minor points.
>>
>> On Wed, Jul 24, 2019 at 09:25:47PM +0200, René van Dorst wrote:
>
> <snip>
>
>>> +
>>> +static void mt7530_phylink_validate(struct dsa_switch *ds, int port,
>>> + unsigned long *supported,
>>> + struct phylink_link_state *state)
>>> +{
>>> + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
>>> +
>>> + switch (port) {
>>> + case 0: /* Internal phy */
>>> + case 1:
>>> + case 2:
>>> + case 3:
>>> + case 4:
>>> + if (state->interface != PHY_INTERFACE_MODE_NA &&
>>> + state->interface != PHY_INTERFACE_MODE_GMII)
>>> + goto unsupported;
>>> + break;
>>> + /* case 5: Port 5 not supported! */
>>> + case 6: /* 1st cpu port */
>>> + if (state->interface != PHY_INTERFACE_MODE_NA &&
>>> + state->interface != PHY_INTERFACE_MODE_RGMII &&
>>> + state->interface != PHY_INTERFACE_MODE_TRGMII)
>>> + goto unsupported;
>>> + break;
>>> + default:
>>> + linkmode_zero(supported);
>>> + dev_err(ds->dev, "%s: unsupported port: %i\n", __func__, port);
>>
>> You could reorder this as:
>>
>> default:
>> dev_err(ds->dev, "%s: unsupported port: %i\n", __func__, port);
>> unsupported:
>> linkmode_zero(supported);
>>
>
> Hi David,
>
>> and save having the "unsupported" at the end of the function. Not
>> sure
>> what DaveM would think of it though.
>
> Can you give your option about this?
> So I know what to do with it and make a new series.
Russell's suggestion is fine.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: mt7530: Convert to PHYLINK API
From: René van Dorst @ 2019-08-01 17:21 UTC (permalink / raw)
To: davem
Cc: netdev, frank-w, sean.wang, f.fainelli, matthias.bgg, andrew,
vivien.didelot, john, linux-mediatek, linux-mips, robh+dt,
devicetree, Russell King - ARM Linux admin
In-Reply-To: <20190727184828.GT1330@shell.armlinux.org.uk>
Quoting Russell King - ARM Linux admin <linux@armlinux.org.uk>:
> Hi,
>
> Just a couple of minor points.
>
> On Wed, Jul 24, 2019 at 09:25:47PM +0200, René van Dorst wrote:
<snip>
>> +
>> +static void mt7530_phylink_validate(struct dsa_switch *ds, int port,
>> + unsigned long *supported,
>> + struct phylink_link_state *state)
>> +{
>> + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
>> +
>> + switch (port) {
>> + case 0: /* Internal phy */
>> + case 1:
>> + case 2:
>> + case 3:
>> + case 4:
>> + if (state->interface != PHY_INTERFACE_MODE_NA &&
>> + state->interface != PHY_INTERFACE_MODE_GMII)
>> + goto unsupported;
>> + break;
>> + /* case 5: Port 5 not supported! */
>> + case 6: /* 1st cpu port */
>> + if (state->interface != PHY_INTERFACE_MODE_NA &&
>> + state->interface != PHY_INTERFACE_MODE_RGMII &&
>> + state->interface != PHY_INTERFACE_MODE_TRGMII)
>> + goto unsupported;
>> + break;
>> + default:
>> + linkmode_zero(supported);
>> + dev_err(ds->dev, "%s: unsupported port: %i\n", __func__, port);
>
> You could reorder this as:
>
> default:
> dev_err(ds->dev, "%s: unsupported port: %i\n", __func__, port);
> unsupported:
> linkmode_zero(supported);
>
Hi David,
> and save having the "unsupported" at the end of the function. Not sure
> what DaveM would think of it though.
Can you give your option about this?
So I know what to do with it and make a new series.
Greats,
René
>
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next] net: phy: xgene: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-01 17:16 UTC (permalink / raw)
To: yuehaibing
Cc: iyappan, keyur, quan, andrew, f.fainelli, hkallweit1,
linux-kernel, netdev
In-Reply-To: <20190801124630.5656-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 1 Aug 2019 20:46:30 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bcm63xx_enet: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-01 17:16 UTC (permalink / raw)
To: yuehaibing
Cc: f.fainelli, bcm-kernel-feedback-list, andrew, linux-arm-kernel,
linux-kernel, netdev
In-Reply-To: <20190801123908.62396-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 1 Aug 2019 20:39:08 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: qcom/emac: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-01 17:16 UTC (permalink / raw)
To: yuehaibing; +Cc: timur, linux-kernel, netdev
In-Reply-To: <20190801123430.41672-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 1 Aug 2019 20:34:30 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: mediatek: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-01 17:16 UTC (permalink / raw)
To: yuehaibing
Cc: nbd, john, sean.wang, nelson.chang, matthias.bgg, linux-kernel,
netdev, linux-mediatek, linux-arm-kernel
In-Reply-To: <20190801123308.20924-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 1 Aug 2019 20:33:08 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: bcm_sf2: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-01 17:15 UTC (permalink / raw)
To: yuehaibing; +Cc: andrew, vivien.didelot, f.fainelli, linux-kernel, netdev
In-Reply-To: <20190801122911.30992-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 1 Aug 2019 20:29:11 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: b53: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-01 17:15 UTC (permalink / raw)
To: yuehaibing; +Cc: f.fainelli, andrew, vivien.didelot, linux-kernel, netdev
In-Reply-To: <20190801122732.37216-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 1 Aug 2019 20:27:32 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: lantiq: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-01 17:15 UTC (permalink / raw)
To: yuehaibing
Cc: hauke, andrew, vivien.didelot, f.fainelli, linux-kernel, netdev
In-Reply-To: <20190801122546.8516-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 1 Aug 2019 20:25:46 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] mvpp2: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-01 17:15 UTC (permalink / raw)
To: yuehaibing; +Cc: antoine.tenart, maxime.chevallier, linux-kernel, netdev
In-Reply-To: <20190801122202.7800-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 1 Aug 2019 20:22:02 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v2] mvpp2: fix panic on module removal
From: David Miller @ 2019-08-01 17:08 UTC (permalink / raw)
To: mcroce
Cc: netdev, miquel.raynal, linux-kernel, lorenzo, antoine.tenart,
maxime.chevallier, mw, stefanc
In-Reply-To: <20190801121330.30823-1-mcroce@redhat.com>
From: Matteo Croce <mcroce@redhat.com>
Date: Thu, 1 Aug 2019 14:13:30 +0200
> mvpp2 uses a delayed workqueue to gather traffic statistics.
> On module removal the workqueue can be destroyed before calling
> cancel_delayed_work_sync() on its works.
> Fix it by moving the destroy_workqueue() call after mvpp2_port_remove().
> Also remove an unneeded call to flush_workqueue()
...
> Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH bpf-next v10 10/10] landlock: Add user and kernel documentation for Landlock
From: Mickaël Salaün @ 2019-08-01 17:03 UTC (permalink / raw)
To: Randy Dunlap, Mickaël Salaün, linux-kernel
Cc: Alexander Viro, Alexei Starovoitov, Andrew Morton,
Andy Lutomirski, Arnaldo Carvalho de Melo, Casey Schaufler,
Daniel Borkmann, David Drysdale, David S . Miller,
Eric W . Biederman, James Morris, Jann Horn, John Johansen,
Jonathan Corbet, Kees Cook, Michael Kerrisk, Paul Moore,
Sargun Dhillon, Serge E . Hallyn, Shuah Khan, Stephen Smalley,
Tejun Heo, Tetsuo Handa, Thomas Graf, Tycho Andersen, Will Drewry,
kernel-hardening, linux-api, linux-fsdevel, linux-security-module,
netdev
In-Reply-To: <88e90c22-1b78-c2f2-8823-fa776265361c@infradead.org>
Thanks for this spelling fixes. Some comments:
On 31/07/2019 03:53, Randy Dunlap wrote:
> On 7/21/19 2:31 PM, Mickaël Salaün wrote:
>> This documentation can be built with the Sphinx framework.
>>
>> Signed-off-by: Mickaël Salaün <mic@digikod.net>
>> Cc: Alexei Starovoitov <ast@kernel.org>
>> Cc: Andy Lutomirski <luto@amacapital.net>
>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: James Morris <jmorris@namei.org>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: Serge E. Hallyn <serge@hallyn.com>
>> ---
>>
>> Changes since v9:
>> * update with expected attach type and expected attach triggers
>>
>> Changes since v8:
>> * remove documentation related to chaining and tagging according to this
>> patch series
>>
>> Changes since v7:
>> * update documentation according to the Landlock revamp
>>
>> Changes since v6:
>> * add a check for ctx->event
>> * rename BPF_PROG_TYPE_LANDLOCK to BPF_PROG_TYPE_LANDLOCK_RULE
>> * rename Landlock version to ABI to better reflect its purpose and add a
>> dedicated changelog section
>> * update tables
>> * relax no_new_privs recommendations
>> * remove ABILITY_WRITE related functions
>> * reword rule "appending" to "prepending" and explain it
>> * cosmetic fixes
>>
>> Changes since v5:
>> * update the rule hierarchy inheritance explanation
>> * briefly explain ctx->arg2
>> * add ptrace restrictions
>> * explain EPERM
>> * update example (subtype)
>> * use ":manpage:"
>> ---
>> Documentation/security/index.rst | 1 +
>> Documentation/security/landlock/index.rst | 20 +++
>> Documentation/security/landlock/kernel.rst | 99 ++++++++++++++
>> Documentation/security/landlock/user.rst | 147 +++++++++++++++++++++
>> 4 files changed, 267 insertions(+)
>> create mode 100644 Documentation/security/landlock/index.rst
>> create mode 100644 Documentation/security/landlock/kernel.rst
>> create mode 100644 Documentation/security/landlock/user.rst
>
>
>> diff --git a/Documentation/security/landlock/kernel.rst b/Documentation/security/landlock/kernel.rst
>> new file mode 100644
>> index 000000000000..7d1e06d544bf
>> --- /dev/null
>> +++ b/Documentation/security/landlock/kernel.rst
>> @@ -0,0 +1,99 @@
>> +==============================
>> +Landlock: kernel documentation
>> +==============================
>> +
>> +eBPF properties
>> +===============
>> +
>> +To get an expressive language while still being safe and small, Landlock is
>> +based on eBPF. Landlock should be usable by untrusted processes and must
>> +therefore expose a minimal attack surface. The eBPF bytecode is minimal,
>> +powerful, widely used and designed to be used by untrusted applications. Thus,
>> +reusing the eBPF support in the kernel enables a generic approach while
>> +minimizing new code.
>> +
>> +An eBPF program has access to an eBPF context containing some fields used to
>> +inspect the current object. These arguments can be used directly (e.g. cookie)
>> +or passed to helper functions according to their types (e.g. inode pointer). It
>> +is then possible to do complex access checks without race conditions or
>> +inconsistent evaluation (i.e. `incorrect mirroring of the OS code and state
>> +<https://www.ndss-symposium.org/ndss2003/traps-and-pitfalls-practical-problems-system-call-interposition-based-security-tools/>`_).
>> +
>> +A Landlock hook describes a particular access type. For now, there is two
>
> there are two
>
>> +hooks dedicated to filesystem related operations: LANDLOCK_HOOK_FS_PICK and
>> +LANDLOCK_HOOK_FS_WALK. A Landlock program is tied to one hook. This makes it
>> +possible to statically check context accesses, potentially performed by such
>> +program, and hence prevents kernel address leaks and ensure the right use of
>
> ensures
>
>> +hook arguments with eBPF functions. Any user can add multiple Landlock
>> +programs per Landlock hook. They are stacked and evaluated one after the
>> +other, starting from the most recent program, as seccomp-bpf does with its
>> +filters. Underneath, a hook is an abstraction over a set of LSM hooks.
>> +
>> +
>> +Guiding principles
>> +==================
>> +
>> +Unprivileged use
>> +----------------
>> +
>> +* Landlock helpers and context should be usable by any unprivileged and
>> + untrusted program while following the system security policy enforced by
>> + other access control mechanisms (e.g. DAC, LSM).
>> +
>> +
>> +Landlock hook and context
>> +-------------------------
>> +
>> +* A Landlock hook shall be focused on access control on kernel objects instead
>> + of syscall filtering (i.e. syscall arguments), which is the purpose of
>> + seccomp-bpf.
>> +* A Landlock context provided by a hook shall express the minimal and more
>> + generic interface to control an access for a kernel object.
>> +* A hook shall guaranty that all the BPF function calls from a program are> + safe. Thus, the related Landlock context arguments shall always be of the
>> + same type for a particular hook. For example, a network hook could share
>> + helpers with a file hook because of UNIX socket. However, the same helpers
>> + may not be compatible for a file system handle and a net handle.
>> +* Multiple hooks may use the same context interface.
>> +
>> +
>> +Landlock helpers
>> +----------------
>> +
>> +* Landlock helpers shall be as generic as possible while at the same time being
>> + as simple as possible and following the syscall creation principles (cf.
>> + *Documentation/adding-syscalls.txt*).
>> +* The only behavior change allowed on a helper is to fix a (logical) bug to
>> + match the initial semantic.
>> +* Helpers shall be reentrant, i.e. only take inputs from arguments (e.g. from
>> + the BPF context), to enable a hook to use a cache. Future program options
>> + might change this cache behavior.
>> +* It is quite easy to add new helpers to extend Landlock. The main concern
>> + should be about the possibility to leak information from the kernel that may
>> + not be accessible otherwise (i.e. side-channel attack).
>> +
>> +
>> +Questions and answers
>> +=====================
>> +
>> +Why not create a custom hook for each kind of action?
>> +-----------------------------------------------------
>> +
>> +Landlock programs can handle these checks. Adding more exceptions to the
>> +kernel code would lead to more code complexity. A decision to ignore a kind of
>> +action can and should be done at the beginning of a Landlock program.
>> +
>> +
>> +Why a program does not return an errno or a kill code?
>> +------------------------------------------------------
>> +
>> +seccomp filters can return multiple kind of code, including an errno value or a
>
> kinds
>
>> +kill signal, which may be convenient for access control. Those return codes
>> +are hardwired in the userland ABI. Instead, Landlock's approach is to return a
>> +boolean to allow or deny an action, which is much simpler and more generic.
>> +Moreover, we do not really have a choice because, unlike to seccomp, Landlock
>> +programs are not enforced at the syscall entry point but may be executed at any
>> +point in the kernel (through LSM hooks) where an errno return code may not make
>> +sense. However, with this simple ABI and with the ability to call helpers,
>> +Landlock may gain features similar to seccomp-bpf in the future while being
>> +compatible with previous programs.
>> diff --git a/Documentation/security/landlock/user.rst b/Documentation/security/landlock/user.rst
>> new file mode 100644
>> index 000000000000..14c4f3b377bd
>> --- /dev/null
>> +++ b/Documentation/security/landlock/user.rst
>> @@ -0,0 +1,147 @@
>> +================================
>> +Landlock: userland documentation
>> +================================
>> +
>> +Landlock programs
>> +=================
>> +
>> +eBPF programs are used to create security programs. They are contained and can
>> +call only a whitelist of dedicated functions. Moreover, they can only loop
>> +under strict conditions, which protects from denial of service. More
>> +information on BPF can be found in *Documentation/networking/filter.txt*.
>> +
>> +
>> +Writing a program
>> +-----------------
>> +
>> +To enforce a security policy, a thread first needs to create a Landlock program.
>> +The easiest way to write an eBPF program depicting a security program is to write
>> +it in the C language. As described in *samples/bpf/README.rst*, LLVM can
>> +compile such programs. Files *samples/bpf/landlock1_kern.c* and those in
>> +*tools/testing/selftests/landlock/* can be used as examples.
>> +
>> +Once the eBPF program is created, the next step is to create the metadata
>> +describing the Landlock program. This metadata includes an expected attach type which
>> +contains the hook type to which the program is tied, and expected attach
>> +triggers which identify the actions for which the program should be run.
>> +
>> +A hook is a policy decision point which exposes the same context type for
>> +each program evaluation.
>> +
>> +A Landlock hook describes the kind of kernel object for which a program will be
>> +triggered to allow or deny an action. For example, the hook
>> +BPF_LANDLOCK_FS_PICK can be triggered every time a landlocked thread performs a
>> +set of action related to the filesystem (e.g. open, read, write, mount...).
>
> actions
>
>> +This actions are identified by the `triggers` bitfield.
>> +
>> +The next step is to fill a :c:type:`struct bpf_load_program_attr
>> +<bpf_load_program_attr>` with BPF_PROG_TYPE_LANDLOCK_HOOK, the expected attach
>> +type and other BPF program metadata. This bpf_attr must then be passed to the
>> +:manpage:`bpf(2)` syscall alongside the BPF_PROG_LOAD command. If everything
>> +is deemed correct by the kernel, the thread gets a file descriptor referring to
>> +this program.
>> +
>> +In the following code, the *insn* variable is an array of BPF instructions
>> +which can be extracted from an ELF file as is done in bpf_load_file() from
>> +*samples/bpf/bpf_load.c*.
>
> A little confusing. Is there a mixup of <insn> and <insns>?
Indeed, a typo was inserted with a rewrite of this part.
>
>> +
>> +.. code-block:: c
>> +
>> + int prog_fd;
>> + struct bpf_load_program_attr load_attr;
>> +
>> + memset(&load_attr, 0, sizeof(struct bpf_load_program_attr));
>> + load_attr.prog_type = BPF_PROG_TYPE_LANDLOCK_HOOK;
>> + load_attr.expected_attach_type = BPF_LANDLOCK_FS_PICK;
>> + load_attr.expected_attach_triggers = LANDLOCK_TRIGGER_FS_PICK_OPEN;
>> + load_attr.insns = insns;
>> + load_attr.insns_cnt = sizeof(insn) / sizeof(struct bpf_insn);
>> + load_attr.license = "GPL";
>> +
>> + prog_fd = bpf_load_program_xattr(&load_attr, log_buf, log_buf_sz);
>> + if (prog_fd == -1)
>> + exit(1);
>> +
>> +
>> +Enforcing a program
>> +-------------------
>> +
>> +Once the Landlock program has been created or received (e.g. through a UNIX
>> +socket), the thread willing to sandbox itself (and its future children) should
>> +perform the following two steps.
>> +
>> +The thread should first request to never be allowed to get new privileges with a
>> +call to :manpage:`prctl(2)` and the PR_SET_NO_NEW_PRIVS option. More
>> +information can be found in *Documentation/prctl/no_new_privs.txt*.
>> +
>> +.. code-block:: c
>> +
>> + if (prctl(PR_SET_NO_NEW_PRIVS, 1, NULL, 0, 0))
>> + exit(1);
>> +
>> +A thread can apply a program to itself by using the :manpage:`seccomp(2)` syscall.
>> +The operation is SECCOMP_PREPEND_LANDLOCK_PROG, the flags must be empty and the
>> +*args* argument must point to a valid Landlock program file descriptor.
>> +
>> +.. code-block:: c
>> +
>> + if (seccomp(SECCOMP_PREPEND_LANDLOCK_PROG, 0, &fd))
>> + exit(1);
>> +
>> +If the syscall succeeds, the program is now enforced on the calling thread and
>> +will be enforced on all its subsequently created children of the thread as
>> +well. Once a thread is landlocked, there is no way to remove this security
>> +policy, only stacking more restrictions is allowed. The program evaluation is
>> +performed from the newest to the oldest.
>> +
>> +When a syscall ask for an action on a kernel object, if this action is denied,
>
> asks
>
>> +then an EACCES errno code is returned through the syscall.
>> +
>> +
>> +.. _inherited_programs:
>> +
>> +Inherited programs
>> +------------------
>> +
>> +Every new thread resulting from a :manpage:`clone(2)` inherits Landlock program
>> +restrictions from its parent. This is similar to the seccomp inheritance as
>> +described in *Documentation/prctl/seccomp_filter.txt*.
>> +
>> +
>> +Ptrace restrictions
>> +-------------------
>> +
>> +A landlocked process has less privileges than a non-landlocked process and must
>> +then be subject to additional restrictions when manipulating another process.
>> +To be allowed to use :manpage:`ptrace(2)` and related syscalls on a target
>> +process, a landlocked process must have a subset of the target process programs.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Maybe that last statement is correct, but it seems to me that it is missing something.
What about this:
To be allowed to trace a process (using :manpage:`ptrace(2)`), a
landlocked tracer process must only be constrained by a subset (possibly
empty) of the Landlock programs which are also applied to the tracee.
This ensure that the tracer has less or the same constraints than the
tracee, hence protecting against privilege escalation.
>
>> +
>> +
>> +Landlock structures and constants
>> +=================================
>> +
>> +Hook types
>> +----------
>> +
>> +.. kernel-doc:: include/uapi/linux/landlock.h
>> + :functions: landlock_hook_type
>> +
>> +
>> +Contexts
>> +--------
>> +
>> +.. kernel-doc:: include/uapi/linux/landlock.h
>> + :functions: landlock_ctx_fs_pick landlock_ctx_fs_walk landlock_ctx_fs_get
>> +
>> +
>> +Triggers for fs_pick
>> +--------------------
>> +
>> +.. kernel-doc:: include/uapi/linux/landlock.h
>> + :functions: landlock_triggers
>> +
>> +
>> +Additional documentation
>> +========================
>> +
>> +See https://landlock.io
>>
>
>
--
Mickaël Salaün
ANSSI/SDE/ST/LAM
Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.
^ permalink raw reply
* Re: [PATCH v2 net-next] be2net: disable bh with spin_lock in be_process_mcc
From: David Miller @ 2019-08-01 16:55 UTC (permalink / raw)
To: kda; +Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, netdev
In-Reply-To: <20190801092420.34502-1-dkirjanov@suse.com>
From: Denis Kirjanov <kda@linux-powerpc.org>
Date: Thu, 1 Aug 2019 11:24:20 +0200
> be_process_mcc() is invoked in 3 different places and
> always with BHs disabled except the be_poll function
> but since it's invoked from softirq with BHs
> disabled it won't hurt.
>
> v1->v2: added explanation to the patch
>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Like Willem I see no benefit at all to this change.
^ permalink raw reply
* Re: [PATCH net] ibmveth: use net_err_ratelimited when set_multicast_list
From: David Miller @ 2019-08-01 16:51 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, tlfalcon
In-Reply-To: <20190801090347.8258-1-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Thu, 1 Aug 2019 17:03:47 +0800
> When setting lots of multicast list on ibmveth, e.g. add 3000 membership on a
> multicast group, the following error message flushes our log file
>
> 8507 [ 901.478251] ibmveth 30000003 env3: h_multicast_ctrl rc=4 when adding an entry to the filter table
> ...
> 1718386 [ 5636.808658] ibmveth 30000003 env3: h_multicast_ctrl rc=4 when adding an entry to the filter table
>
> We got 1.5 million lines of messages in 1.3h. Let's replace netdev_err() by
> net_err_ratelimited() to avoid this issue. I don't use netdev_err_once() in
> case h_multicast_ctrl() return different lpar_rc types.
>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Let's work on fixing what causes this problem, or adding a retry
mechanism, rather than making the message less painful.
What is worse is that these failures are not in any way communicated
back up the callchain to show that the operation didn't complete
sucessfully.
This is a real mess in behavior and error handling, don't make it
worse please.
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5e: Allow dropping specific tunnel packets
From: David Miller @ 2019-08-01 16:48 UTC (permalink / raw)
To: xiangxia.m.yue; +Cc: roid, saeedm, netdev
In-Reply-To: <1564648859-17369-1-git-send-email-xiangxia.m.yue@gmail.com>
From: xiangxia.m.yue@gmail.com
Date: Thu, 1 Aug 2019 16:40:59 +0800
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> In some case, we don't want to allow specific tunnel packets
> to host that can avoid to take up high CPU (e.g network attacks).
> But other tunnel packets which not matched in hardware will be
> sent to host too.
>
> $ tc filter add dev vxlan_sys_4789 \
> protocol ip chain 0 parent ffff: prio 1 handle 1 \
> flower dst_ip 1.1.1.100 ip_proto tcp dst_port 80 \
> enc_dst_ip 2.2.2.100 enc_key_id 100 enc_dst_port 4789 \
> action tunnel_key unset pipe action drop
>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Saeed, please pick this up.
Thank you.
^ permalink raw reply
* [PATCH] iwlwifi: remove redundant assignment to variable bufsz
From: Colin King @ 2019-08-01 16:44 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, David S . Miller,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The variable bufsz is being initialized with a value that is never
read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index f5df5b370d78..addbbb78b1af 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -2542,7 +2542,7 @@ static ssize_t iwl_dbgfs_rx_queue_read(struct file *file,
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
char *buf;
int pos = 0, i, ret;
- size_t bufsz = sizeof(buf);
+ size_t bufsz;
bufsz = sizeof(char) * 121 * trans->num_rx_queues;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v1 2/2] net: npcm: add NPCM7xx EMC 10/100 Ethernet driver
From: David Miller @ 2019-08-01 16:27 UTC (permalink / raw)
To: avifishman70
Cc: venture, yuenn, benjaminfair, robh+dt, mark.rutland, gregkh,
tmaimon77, tali.perry1, openbmc, netdev, devicetree, linux-kernel,
tglx
In-Reply-To: <20190801072611.27935-3-avifishman70@gmail.com>
From: Avi Fishman <avifishman70@gmail.com>
Date: Thu, 1 Aug 2019 10:26:11 +0300
> +#Eternet 10/100 EMC
"Ethernet"
> +#ifdef CONFIG_NPCM7XX_EMC_ETH_DEBUG
> +#define DEBUG
> +#endif
Please don't control the DEBUG define in this way.
> +#if defined CONFIG_NPCM7XX_EMC_ETH_DEBUG || defined CONFIG_DEBUG_FS
> +#define REG_PRINT(reg_name) {t = scnprintf(next, size, "%-10s = %08X\n", \
> + #reg_name, readl(ether->reg + (reg_name))); size -= t; next += t; }
> +#define DUMP_PRINT(f, x...) {t = scnprintf(next, size, f, ## x); size -= t; \
> + next += t; }
Really, get rid of this custom debugging infrastructure and just use
generic facilities the kernel has for this, as designed.
> +static int npcm7xx_info_dump(char *buf, int count, struct net_device *netdev)
> +{
> + struct npcm7xx_ether *ether = netdev_priv(netdev);
> + struct npcm7xx_txbd *txbd;
> + struct npcm7xx_rxbd *rxbd;
> + unsigned long flags;
> + unsigned int i, cur, txd_offset, rxd_offset;
> + char *next = buf;
> + unsigned int size = count;
> + int t;
> + int is_locked = spin_is_locked(ðer->lock);
Reverse christmas tree (longest to shortest) ordering for local variables
please.
Audit your entire submission for this problem.
^ permalink raw reply
* RE: [PATCH v2 00/11] VSOCK: add vsock_test test suite
From: Dexuan Cui @ 2019-08-01 16:16 UTC (permalink / raw)
To: Stefano Garzarella, netdev@vger.kernel.org
Cc: kvm@vger.kernel.org, Stefan Hajnoczi,
virtualization@lists.linux-foundation.org, David S. Miller,
Jorgen Hansen, linux-kernel@vger.kernel.org
In-Reply-To: <20190801152541.245833-1-sgarzare@redhat.com>
> From: Stefano Garzarella <sgarzare@redhat.com>
> Sent: Thursday, August 1, 2019 8:26 AM
>
> The vsock_diag.ko module already has a test suite but the core AF_VSOCK
> functionality has no tests. This patch series adds several test cases that
> exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv,
> connect/accept,
> half-closed connections, simultaneous connections).
>
> Dexuan: Do you think can be useful to test HyperV?
Hi Stefano,
Thanks! This should be useful, though I have to write the Windows host side
code to use the test program(s). :-)
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH v2 10/11] vsock_test: skip read() in test_stream*close tests on a VMCI host
From: Stefano Garzarella @ 2019-08-01 15:58 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, kvm, Stefan Hajnoczi, Dexuan Cui, virtualization,
David S. Miller, Jorgen Hansen, linux-kernel
In-Reply-To: <79ffb2a6-8ed2-cce2-7704-ed872446c0fe@cogentembedded.com>
On Thu, Aug 01, 2019 at 06:53:32PM +0300, Sergei Shtylyov wrote:
> Hello!
>
Hi :)
> On 08/01/2019 06:25 PM, Stefano Garzarella wrote:
>
> > When VMCI transport is used, if the guest closes a connection,
> > all data is gone and EOF is returned, so we should skip the read
> > of data written by the peer before closing the connection.
> >
> > Reported-by: Jorgen Hansen <jhansen@vmware.com>
> > Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> > ---
> > tools/testing/vsock/vsock_test.c | 26 ++++++++++++++++++++++++--
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
> > index cb606091489f..64adf45501ca 100644
> > --- a/tools/testing/vsock/vsock_test.c
> > +++ b/tools/testing/vsock/vsock_test.c
> [...]
> > @@ -79,16 +80,27 @@ static void test_stream_client_close_server(const struct test_opts *opts)
> > exit(EXIT_FAILURE);
> > }
> >
> > + local_cid = vsock_get_local_cid(fd);
> > +
> > control_expectln("CLOSED");
> >
> > send_byte(fd, -EPIPE);
> > - recv_byte(fd, 1);
> > +
> > + /* Skip the read of data wrote by the peer if we are on VMCI and
>
> s/wrote/written/?
>
Thanks, I'll fix it!
Stefano
> > + * we are on the host side, because when the guest closes a
> > + * connection, all data is gone and EOF is returned.
> > + */
> > + if (!(opts->transport == TEST_TRANSPORT_VMCI &&
> > + local_cid == VMADDR_CID_HOST))
> > + recv_byte(fd, 1);
> > +
> > recv_byte(fd, 0);
> > close(fd);
> > }
> [...]
>
> MBR, Sergei
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox