[PATCH RESEND v1] locking/ww_mutex: Prevent read of uninitialized memory
On "missed ABBA deadlock" abba.result is read, but not initialized
in all situations.
Detected by CoverityScan, CID#1402035 ("Uninitialized scalar variable")
Signed-off-by: Robert Foss
---
kernel/locking/test-ww_mutex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
index 6b7abb334ca6..beb76693ccfa 100644
--- a/kernel/locking/test-ww_mutex.c
+++ b/kernel/locking/test-ww_mutex.c
@@ -196,7 +196,7 @@ static void test_abba_work(struct work_struct *work)
static int test_abba(bool resolve)
{
- struct test_abba abba;
+ struct test_abba abba = { 0 };
struct ww_acquire_ctx ctx;
int err, ret;
--
2.11.0.453.g787f75f05
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On 03/14/2017 07:47 AM, Benjamin Gaignard wrote: > 2017-03-13 22:09 GMT+01:00 Laura Abbott : >> On 03/12/2017 12:05 PM, Daniel Vetter wrote: >>> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard >>> wrote: 2017-03-09 18:38 GMT+01:00 Laura Abbott : > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: >> 2017-03-06 17:04 GMT+01:00 Daniel Vetter : >>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote: On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote: > No one gave a thing about android in upstream, so Greg KH just dumped > it > all into staging/android/. We've discussed ION a bunch of times, > recorded > anything we'd like to fix in staging/android/TODO, and Laura's patch > series here addresses a big chunk of that. > This is pretty much the same approach we (gpu folks) used to de-stage > the > syncpt stuff. Well, there's also the fact that quite a few people have issues with the design (like Laurent). It seems like a lot of them have either got more comfortable with it over time, or at least not managed to come up with any better ideas in the meantime. >>> >>> See the TODO, it has everything a really big group (look at the patch >>> for >>> the full Cc: list) figured needs to be improved at LPC 2015. We don't >>> just >>> merge stuff because merging stuff is fun :-) >>> >>> Laurent was even in that group ... >>> -Daniel >> >> For me those patches are going in the right direction. >> >> I still have few questions: >> - since alignment management has been remove from ion-core, should it >> be also removed from ioctl structure ? > > Yes, I think I'm going to go with the suggestion to fixup the ABI > so we don't need the compat layer and as part of that I'm also > dropping the align argument. > >> - can you we ride off ion_handle (at least in userland) and only >> export a dma-buf descriptor ? > > Yes, I think this is the right direction given we're breaking > everything anyway. I was debating trying to keep the two but > moving to only dma bufs is probably cleaner. The only reason > I could see for keeping the handles is running out of file > descriptors for dma-bufs but that seems unlikely. >> >> In the future how can we add new heaps ? >> Some platforms have very specific memory allocation >> requirements (just have a look in the number of gem custom allocator in >> drm) >> Do you plan to add heap type/mask for each ? > > Yes, that was my thinking. My concern is about the policy to adding heaps, will you accept "customs" heap per platforms ? per devices ? or only generic ones ? If you are too strict, we will have lot of out-of-tree heaps and if you accept of of them it will be a nightmare to maintain >>> >>> I think ion should expose any heap that's also directly accessible to >>> devices using dma_alloc(_coherent). That should leave very few things >>> left, like your SMA heap. >>> Another point is how can we put secure rules (like selinux policy) on heaps since all the allocations go to the same device (/dev/ion) ? For example, until now, in Android we have to give the same access rights to all the process that use ION. It will become problem when we will add secure heaps because we won't be able to distinguish secure processes to standard ones or set specific policy per heaps. Maybe I'm wrong here but I have never see selinux policy checking an ioctl field but if that exist it could be a solution. >>> >>> Hm, we might want to expose all the heaps as individual >>> /dev/ion_$heapname nodes? Should we do this from the start, since >>> we're massively revamping the uapi anyway (imo not needed, current >>> state seems to work too)? >>> -Daniel >>> >> >> I thought about that. One advantage with separate /dev/ion_$heap > > Should we use /devi/ion/$heap instead of /dev/ion_$heap ? > I think it would be easier for user to look into one directory rather > then in whole /dev to find the heaps > If we decide to move away from /dev/ion we can consider it. >> is that we don't have to worry about a limit of 32 possible >> heaps per system (32-bit heap id allocation field). But dealing >> with an ioctl seems easier than names. Userspace might be less >> likely to hardcode random id numbers vs. names as well. > > In the futur I think that heap type will be replaced by a "get caps" > ioctl which will > describe heap capabilities. At least that is my understanding of kernel part > of "unix memory allocator" project > I don't think it will be completely replaced. A heap can have multiple capabilities so I suspect there will need to be some cap -> allocation instance translation.
Re: [PATCH 3/4] x86, pci: Add interface to force mmconfig
On Tue, Mar 14, 2017 at 06:56:26PM +0100, Thomas Gleixner wrote: > On Tue, 14 Mar 2017, Andi Kleen wrote: > > The other option is to simply make it unconditional. That would > > be even simpler, but it is a bit more risky. Hmm, I suppose may > > be worth trying to find out what Windows uses. If they get away > > with MMCONFIG everywhere we should be too. > > From the PCIe spec: > > The PCI 3.0 compatible Configuration Space can be accessed using either > the mechanism defined in the PCI Local Bus Specification or the PCI > Express Enhanced Configuration Access Mechanism (ECAM) described later in > this section. Accesses made using either access mechanism are > equivalent. The PCI Express Extended Configuration Space can only be > accessed by using the ECAM. > > The 1.0 spec has a similar wording (s/3.0/2.3). > > Definitely the best way to go. I agree that it should be fairly safe to do ECAM/MMCONFIG without locking. Can we handle the decision part by adding a "lockless" bit to struct pci_ops? Old ops don't mention that bit, so it will be initialized to zero and we'll do locking as today. ECAM/MMCONFIG ops can set it and we can skip the locking. Bjorn
Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form
On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote: > Krzysztof Kozlowski wrote: > > On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: > >> Hello Krzysztof, > >> > >> I was wondering about the benefit of this. From a quick look these are > >> all messages that end up in the kernel log / dmesg. > >> > >> IIRC %pK does nothing there, since dmest_restrict is supposed to be used > >> to deny an unpriviliged user the access to the kernel log. > >> > >> Or am I missing something here? > > > > These are regular printks so depending on kernel options (e.g. dynamic > > debug, drm.debug) these might be printed also in the console. Of course > > we could argue then if access to one of the consoles is worth > > securing. > This here suggests otherwise. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt#n388 > > I have not tested this, but IIRC %pK is not honored by the kernel > logging infrastucture. That's why dmesg_restrict is there. > > Correct me if I'm wrong. The %pK will not help for dmesg or /proc/kmsg but it will help for console (/dev/ttySACN, ttySN etc) because effectively it uses the same vsprintf()/pointer() functions. As I said, we could argue whether securing console is worth... usually attacker having access to it has also physical access to the machine so everything gets easier... Best regards, Krzysztof
Re: [PATCH 2/2] perf: xgene: Add support for SoC PMU of next generation of X-Gene
On Tue, Mar 14, 2017 at 11:06:52AM -0700, Hoan Tran wrote:
> This patch adds support for SoC-wide (AKA uncore) Performance Monitoring
> Unit in the next generation of X-Gene SoC.
>
> Signed-off-by: Hoan Tran
> ---
> drivers/perf/xgene_pmu.c | 645
> ++-
> 1 file changed, 575 insertions(+), 70 deletions(-)
That's a very large number of additions, and a very short commit
message.
Please expand the commit message, outlining the differences in this new
version of the PMU HW, and the structural changes made to the driver to
accommodate this.
Additionally, I think that this amount of change should be split into
separate patches. More on that below.
[...]
> static inline void xgene_pmu_mask_int(struct xgene_pmu *xgene_pmu)
> {
> - writel(PCPPMU_INTENMASK, xgene_pmu->pcppmu_csr + PCPPMU_INTMASK_REG);
> + if (xgene_pmu->version == PCP_PMU_V3) {
> + writel(PCPPMU_V3_INTENMASK,
> +xgene_pmu->pcppmu_csr + PCPPMU_INTMASK_REG);
> + } else {
> + writel(PCPPMU_INTENMASK,
> +xgene_pmu->pcppmu_csr + PCPPMU_INTMASK_REG);
> + }
> }
Having all these version checks in the leaf functions is horrible,
especially given that in cases like xgene_pmu_read_counter(), the v3
behaviour is *substantially* different to the v1/v2 behaviour.
Please use function pointers in the xgene_pmu/xgene_pmu_dev structures
instead. That way you can clearly separate the v3 code and the v1/v2
code, and only need to distinguish the two at init time.
Please move the existing code over to function pointers with preparatory
patches, with the v3 code introduced afterwards.
That applies to almost all cases where you check xgene_pmu->version,
excluding those that happen during probing.
> -static inline u32 xgene_pmu_read_counter(struct xgene_pmu_dev *pmu_dev, int
> idx)
> +static inline u64 xgene_pmu_read_counter(struct xgene_pmu_dev *pmu_dev, int
> idx)
> {
> - return readl(pmu_dev->inf->csr + PMU_PMEVCNTR0 + (4 * idx));
> + u32 cnt_lo, cnt_hi, cnt_hi2;
> +
> + if (pmu_dev->parent->version == PCP_PMU_V3) {
> + /*
> + * v3 has 64-bit counter registers composed by 2 32-bit
> registers
> + * This can be a problem if the counter increases and carries
> + * out of bit [31] between 2 reads. The extra reads would help
> + * to prevent this issue.
> + */
> + while (1) {
> + cnt_hi = readl(pmu_dev->inf->csr + PMU_PMEVCNTR0 + 4 +
> (8 * idx));
> + cnt_lo = readl(pmu_dev->inf->csr + PMU_PMEVCNTR0 + (8 *
> idx));
> + cnt_hi2 = readl(pmu_dev->inf->csr + PMU_PMEVCNTR0 + 4 +
> (8 * idx));
> + if (cnt_hi == cnt_hi2)
> + return (((u64)cnt_hi << 32) | cnt_lo);
> + }
> + }
> +
> + return ((u64)readl(pmu_dev->inf->csr + PMU_PMEVCNTR0 + (4 * idx)));
> }
It would be far simpler and easier to follow, if we did something like:
static inline u64 xgene_pmu_read_counter32(struct xgene_pmu_dev *pmu_dev, int
idx)
{
return readl(pmu_dev->inf->csr + PMU_PMEVCNTR0 + (4 * idx));
}
static inline u64 xgene_pmu_read_counter64(struct xgene_pmu_dev *pmu_dev, int
idx)
{
u32 lo, hi;
do {
hi = xgene_pmu_read_counter32(dev, 2 * idx);
lo = xgene_pmu_read_counter32(dev, 2 * idx + 1);
} while (hi = xgene_pmu_read_counter32(dev, 2 * idx));
return ((u64)hi << 32) | lo;
}
... with the prototypes the same, we can assign the pointer to the
relevant pmu structure.
[...]
> @@ -595,7 +1008,7 @@ static void xgene_perf_event_set_period(struct
> perf_event *event)
> struct xgene_pmu_dev *pmu_dev = to_pmu_dev(event->pmu);
> struct hw_perf_event *hw = &event->hw;
> /*
> - * The X-Gene PMU counters have a period of 2^32. To account for the
> + * The X-Gene PMU counters have a period of 2^32 or more. To account
> for the
>* possiblity of extreme interrupt latency we program for a period of
>* half that. Hopefully we can handle the interrupt before another 2^31
>* events occur and the counter overtakes its previous value.
> @@ -603,7 +1016,7 @@ static void xgene_perf_event_set_period(struct
> perf_event *event)
> u64 val = 1ULL << 31;
>
> local64_set(&hw->prev_count, val);
> - xgene_pmu_write_counter(pmu_dev, hw->idx, (u32) val);
> + xgene_pmu_write_counter(pmu_dev, hw->idx, val);
> }
Surely we should update the val to give us a 2^63 default period, then?
AFAICT, we still set it to 1ULL << 31 above.
> @@ -758,20 +1174,48 @@ static int xgene_init_perf(struct xgene_pmu_dev
> *pmu_dev, char *name)
>
> switch (pmu->inf->type) {
> case PMU_TYPE_L3C:
> - pmu->attr_groups = l3c_pmu_attr_groups;
> + if (!(xgene_pmu->l3c_active_mask & pmu->inf->enable_mask))
>
[RFC][PATCH] dma-buf: Introduce dma-buf test module
dma-buf is designed to share buffers. Sharing means that there needs to
be another subsystem to accept those buffers. Introduce a simple test
module to act as a dummy system to accept dma_bufs from elsewhere. The
goal is to provide a very simple interface to validate exported buffers
do something reasonable. This is based on ion_test.c that existed for
the Ion framework.
Signed-off-by: Laura Abbott
---
This is basically a drop in of what was available as
drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
parts it might be useful as a more general test module. RFC mostly
to see if this is generally useful or not.
---
drivers/dma-buf/Kconfig | 9 ++
drivers/dma-buf/Makefile | 1 +
drivers/dma-buf/dma-buf-test.c| 309 ++
include/uapi/linux/dma_buf_test.h | 67 +
4 files changed, 386 insertions(+)
create mode 100644 drivers/dma-buf/dma-buf-test.c
create mode 100644 include/uapi/linux/dma_buf_test.h
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index ed3b785..8b3fdb1 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -30,4 +30,13 @@ config SW_SYNC
WARNING: improper use of this can result in deadlocking kernel
drivers from userspace. Intended for test and debug only.
+config DMA_BUF_TEST
+ bool "Test module for dma-buf"
+ default n
+ ---help---
+ A test module to validate dma_buf APIs. This should not be
+ enabled for general use.
+
+ Say N here unless you know you want this.
+
endmenu
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index c33bf88..5029608 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,3 +1,4 @@
obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
+obj-$(CONFIG_DMA_BUF_TEST) += dma-buf-test.o
diff --git a/drivers/dma-buf/dma-buf-test.c b/drivers/dma-buf/dma-buf-test.c
new file mode 100644
index 000..3af131c
--- /dev/null
+++ b/drivers/dma-buf/dma-buf-test.c
@@ -0,0 +1,309 @@
+/*
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License versdma_buf 2, as published by the Free Software Foundatdma_buf, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#define pr_fmt(fmt) "dma-buf-test: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct dma_buf_test_device {
+ struct miscdevice misc;
+};
+
+struct dma_buf_test_data {
+ struct dma_buf *dma_buf;
+ struct device *dev;
+};
+
+static int dma_buf_handle_test_dma(struct device *dev, struct dma_buf *dma_buf,
+ void __user *ptr, size_t offset, size_t size,
+ bool write)
+{
+ int ret = 0;
+ struct dma_buf_attachment *attach;
+ struct sg_table *table;
+ pgprot_t pgprot = pgprot_writecombine(PAGE_KERNEL);
+ enum dma_data_direction dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+ struct sg_page_iter sg_iter;
+ unsigned long offset_page;
+
+ attach = dma_buf_attach(dma_buf, dev);
+ if (IS_ERR(attach))
+ return PTR_ERR(attach);
+
+ table = dma_buf_map_attachment(attach, dir);
+ if (IS_ERR(table))
+ return PTR_ERR(table);
+
+ offset_page = offset >> PAGE_SHIFT;
+ offset %= PAGE_SIZE;
+
+ for_each_sg_page(table->sgl, &sg_iter, table->nents, offset_page) {
+ struct page *page = sg_page_iter_page(&sg_iter);
+ void *vaddr = vmap(&page, 1, VM_MAP, pgprot);
+ size_t to_copy = PAGE_SIZE - offset;
+
+ to_copy = min(to_copy, size);
+ if (!vaddr) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ if (write)
+ ret = copy_from_user(vaddr + offset, ptr, to_copy);
+ else
+ ret = copy_to_user(ptr, vaddr + offset, to_copy);
+
+ vunmap(vaddr);
+ if (ret) {
+ ret = -EFAULT;
+ goto err;
+ }
+ size -= to_copy;
+ if (!size)
+ break;
+ ptr += to_copy;
+ offset = 0;
+ }
+
+err:
+ dma_buf_unmap_attachment(attach, table, dir);
+ dma_buf_detach(dma_buf, attach);
+ return ret;
+}
+
+static int dma_buf_handle_test_ke
[GIT PULL] percpu fixes for v4.11-rc2
Hello, Linus.
percpu changes for v4.11-rc2.
* The allocation path was updating pcpu_nr_empty_pop_pages without the
required locking which can lead to incorrect handling of empty
chunks (e.g. keeping too many around), which is buggy but shouldn't
lead to critical failures. Fixed by adding the locking.
* A trivial patch to drop an unused param from pcpu_get_pages().
Thanks.
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-4.11-fixes
for you to fetch changes up to 8a1df543de8ad879d3c80bdda4c67ac4f82e7ee0:
percpu: remove unused chunk_alloc parameter from pcpu_get_pages() (2017-03-06
15:56:55 -0500)
Tahsin Erdogan (2):
percpu: acquire pcpu_lock when updating pcpu_nr_empty_pop_pages
percpu: remove unused chunk_alloc parameter from pcpu_get_pages()
mm/percpu-vm.c | 7 +++
mm/percpu.c| 5 -
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
index 538998a..9ac6394 100644
--- a/mm/percpu-vm.c
+++ b/mm/percpu-vm.c
@@ -21,7 +21,6 @@ static struct page *pcpu_chunk_page(struct pcpu_chunk *chunk,
/**
* pcpu_get_pages - get temp pages array
- * @chunk: chunk of interest
*
* 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
@@ -30,7 +29,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(struct pcpu_chunk *chunk_alloc)
+static struct page **pcpu_get_pages(void)
{
static struct page **pages;
size_t pages_size = pcpu_nr_units * pcpu_unit_pages * sizeof(pages[0]);
@@ -275,7 +274,7 @@ static int pcpu_populate_chunk(struct pcpu_chunk *chunk,
{
struct page **pages;
- pages = pcpu_get_pages(chunk);
+ pages = pcpu_get_pages();
if (!pages)
return -ENOMEM;
@@ -313,7 +312,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(chunk);
+ pages = pcpu_get_pages();
BUG_ON(!pages);
/* unmap and free */
diff --git a/mm/percpu.c b/mm/percpu.c
index 5696039..60a6488 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1011,8 +1011,11 @@ static void __percpu *pcpu_alloc(size_t size, size_t
align, bool reserved,
mutex_unlock(&pcpu_alloc_mutex);
}
- if (chunk != pcpu_reserved_chunk)
+ if (chunk != pcpu_reserved_chunk) {
+ spin_lock_irqsave(&pcpu_lock, flags);
pcpu_nr_empty_pop_pages -= occ_pages;
+ spin_unlock_irqrestore(&pcpu_lock, flags);
+ }
if (pcpu_nr_empty_pop_pages < PCPU_EMPTY_POP_PAGES_LOW)
pcpu_schedule_balance_work();
--
tejun
[PATCH v2] mmc: meson-gx: fix error path when driver initialization fails before enabling clocks
This patch fixes the case where meson_mmc_probe function fails before core_clk is enabled. Originally, that would result in a try to disable the core clock, and if it was not already enabled, it would result in a kernel warning. This issue is similar to the one with div_clk. Fix it by introducing another error path used only between successfully enabling the core clock, and successfully enabling the div clock. That would ensure that core clock is disabled only if it was enabled before. Signed-off-by: Michał Zegan --- changes since v1: cherry picked on top of mmc next branch drivers/mmc/host/meson-gx-mmc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c index c574e1519623..bd075fef08d4 100644 --- a/drivers/mmc/host/meson-gx-mmc.c +++ b/drivers/mmc/host/meson-gx-mmc.c @@ -743,7 +743,7 @@ static int meson_mmc_probe(struct platform_device *pdev) ret = meson_mmc_clk_init(host); if (ret) - goto free_host; + goto err_core_clk; /* Stop execution */ writel(0, host->regs + SD_EMMC_START); @@ -783,8 +783,9 @@ static int meson_mmc_probe(struct platform_device *pdev) err_div_clk: clk_disable_unprepare(host->cfg_div_clk); -free_host: +err_core_clk: clk_disable_unprepare(host->core_clk); +free_host: mmc_free_host(mmc); return ret; } -- 2.12.0
Re: Synaptics RMI4 touchpad regression in 4.11-rc1
On Mon, Mar 13, 2017 at 10:10:22PM -0700, Cameron Gutman wrote:
> > Compared to hid-multitouch, the RMI stack seems to have
> > completely broken palm rejection and introduced some random
> > jumpiness during fine pointing motions. I don't know if these
> > issues are caused by the above errors or are a separate issue.
> >
> > The error about the bootloader version not being recognized just
> > means that updating the firmware is not supported on this touchpad.
> > It is only the F34 firmware update functionality which is failing to
> > load. The palm rejection and jumps are not related to this error.
> >
>
> Maybe that code path should be changed to not make as much noise when
> it runs on known unsupported hardware. Something like the attached
> patch?
> ---
> diff --git a/drivers/input/rmi4/rmi_f34v7.c b/drivers/input/rmi4/rmi_f34v7.c
> index 56c6c39..1291d9a 100644
> --- a/drivers/input/rmi4/rmi_f34v7.c
> +++ b/drivers/input/rmi4/rmi_f34v7.c
> @@ -1369,9 +1369,9 @@ int rmi_f34v7_probe(struct f34_data *f34)
> } else if (f34->bootloader_id[1] == 7) {
> f34->bl_version = 7;
> } else {
> - dev_err(&f34->fn->dev, "%s: Unrecognized bootloader version\n",
> - __func__);
> - return -EINVAL;
> + dev_info(&f34->fn->dev, "%s: Unsupported bootloader version:
> %u\n",
> + __func__, f34->bootloader_id[1]);
> + return -ENODEV;
> }
>
> memset(&f34->v7.blkcount, 0x00, sizeof(f34->v7.blkcount));
I'm afraid I'm responsible for this. I agree it's very unlikely to be
related to your other issues.
One approach to suppress the extra output would be to turn off
CONFIG_RMI_F34. I think your proposed change in wording would be fine,
though.
cheers
Nick
Re: [PATCH v15 9/9] x86/arch_prctl: Rename 'code' argument to 'option'
On Sat, 11 Mar 2017, Kyle Huey wrote: > arch_prctl arbitrarily changed prctl's 'option' to 'code'. Now that we're > adding additional options, fix that. And why is that at the end of the series instead of being the first patch? Thanks, tglx
Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
On 03/14/17 12:08, Kyle Huey wrote: > > That's largely what we ended up doing. See > https://lkml.org/lkml/2017/2/14/80 and the latest version of this > patch, https://lkml.org/lkml/2017/3/11/197. > Yes, as I said, my mistake. I would still like to see an early-out when none of these flags are set (I just discussed this with tglx on IRC): if (likely(!((tifp|tifn) & (_TIF_BLOCKSTEP|_TIF_NOTSC|_TIF_IO_BITMAP| _TIF_NOCPUID|_TIF_USER_RETURN_NOTIFY return; The USER_RETURN_NOTIFY could really use some sanity: it is a notifier chain with a single in-kernel user, which is KVM on x86 only, but we most likely will need to propagate the flag even if it ends up getting specialized. -hpa
[GIT PULL] workqueue changes for v4.11-rc2
Hello, * If a delayed work is queued with NULL @wq, workqueue code explodes after the timer expires at which point it's difficult to tell who the culprit was. This actually happened and the offender was net/smc this time. Add an explicit sanity check for it in the queueing path. Thanks. The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-4.11-fixes for you to fetch changes up to 637fdbae60d6cb9f6e963c1079d7e0445c86ff7d: workqueue: trigger WARN if queue_delayed_work() is called with NULL @wq (2017-03-06 15:33:42 -0500) Tejun Heo (1): workqueue: trigger WARN if queue_delayed_work() is called with NULL @wq kernel/workqueue.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 072cbc9..c0168b7 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1507,6 +1507,7 @@ static void __queue_delayed_work(int cpu, struct workqueue_struct *wq, struct timer_list *timer = &dwork->timer; struct work_struct *work = &dwork->work; + WARN_ON_ONCE(!wq); WARN_ON_ONCE(timer->function != delayed_work_timer_fn || timer->data != (unsigned long)dwork); WARN_ON_ONCE(timer_pending(timer)); -- tejun
Re: [RFC][PATCH] dma-buf: Introduce dma-buf test module
On Tue, Mar 14, 2017 at 01:04:19PM -0700, Laura Abbott wrote:
>
> dma-buf is designed to share buffers. Sharing means that there needs to
> be another subsystem to accept those buffers. Introduce a simple test
> module to act as a dummy system to accept dma_bufs from elsewhere. The
> goal is to provide a very simple interface to validate exported buffers
> do something reasonable. This is based on ion_test.c that existed for
> the Ion framework.
>
> Signed-off-by: Laura Abbott
> ---
> This is basically a drop in of what was available as
> drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
> parts it might be useful as a more general test module. RFC mostly
> to see if this is generally useful or not.
We already have a test dma-buf driver, which also handles reservation
objects and can create fences to provoke signalling races an all kinds of
other fun. It's drivers/gpu/drm/vgem.
If there's anything missing in there, patches very much welcome.
-Daniel
> ---
> drivers/dma-buf/Kconfig | 9 ++
> drivers/dma-buf/Makefile | 1 +
> drivers/dma-buf/dma-buf-test.c| 309
> ++
> include/uapi/linux/dma_buf_test.h | 67 +
> 4 files changed, 386 insertions(+)
> create mode 100644 drivers/dma-buf/dma-buf-test.c
> create mode 100644 include/uapi/linux/dma_buf_test.h
>
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index ed3b785..8b3fdb1 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -30,4 +30,13 @@ config SW_SYNC
> WARNING: improper use of this can result in deadlocking kernel
> drivers from userspace. Intended for test and debug only.
>
> +config DMA_BUF_TEST
> + bool "Test module for dma-buf"
> + default n
> + ---help---
> + A test module to validate dma_buf APIs. This should not be
> + enabled for general use.
> +
> + Say N here unless you know you want this.
> +
> endmenu
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index c33bf88..5029608 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1,3 +1,4 @@
> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
> obj-$(CONFIG_SYNC_FILE) += sync_file.o
> obj-$(CONFIG_SW_SYNC)+= sw_sync.o sync_debug.o
> +obj-$(CONFIG_DMA_BUF_TEST) += dma-buf-test.o
> diff --git a/drivers/dma-buf/dma-buf-test.c b/drivers/dma-buf/dma-buf-test.c
> new file mode 100644
> index 000..3af131c
> --- /dev/null
> +++ b/drivers/dma-buf/dma-buf-test.c
> @@ -0,0 +1,309 @@
> +/*
> + * Copyright (C) 2013 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License versdma_buf 2, as published by the Free Software Foundatdma_buf,
> and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#define pr_fmt(fmt) "dma-buf-test: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct dma_buf_test_device {
> + struct miscdevice misc;
> +};
> +
> +struct dma_buf_test_data {
> + struct dma_buf *dma_buf;
> + struct device *dev;
> +};
> +
> +static int dma_buf_handle_test_dma(struct device *dev, struct dma_buf
> *dma_buf,
> +void __user *ptr, size_t offset, size_t size,
> +bool write)
> +{
> + int ret = 0;
> + struct dma_buf_attachment *attach;
> + struct sg_table *table;
> + pgprot_t pgprot = pgprot_writecombine(PAGE_KERNEL);
> + enum dma_data_direction dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
> + struct sg_page_iter sg_iter;
> + unsigned long offset_page;
> +
> + attach = dma_buf_attach(dma_buf, dev);
> + if (IS_ERR(attach))
> + return PTR_ERR(attach);
> +
> + table = dma_buf_map_attachment(attach, dir);
> + if (IS_ERR(table))
> + return PTR_ERR(table);
> +
> + offset_page = offset >> PAGE_SHIFT;
> + offset %= PAGE_SIZE;
> +
> + for_each_sg_page(table->sgl, &sg_iter, table->nents, offset_page) {
> + struct page *page = sg_page_iter_page(&sg_iter);
> + void *vaddr = vmap(&page, 1, VM_MAP, pgprot);
> + size_t to_copy = PAGE_SIZE - offset;
> +
> + to_copy = min(to_copy, size);
> + if (!vaddr) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + if (write)
> + ret = copy_from_user(vaddr + offset, ptr, to_copy);
> + else
> + ret = cop
[PATCH 4/4] cdc-acm: remove unused element of struct acm
write_used was introduced with commit 884b600f63dc ("[PATCH] USB: fix acm
trouble with terminals") but never used since.
Signed-off-by: Tobias Herzog
---
drivers/usb/class/cdc-acm.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/class/cdc-acm.h b/drivers/usb/class/cdc-acm.h
index bc07fb2..a916c62 100644
--- a/drivers/usb/class/cdc-acm.h
+++ b/drivers/usb/class/cdc-acm.h
@@ -100,7 +100,6 @@ struct acm {
spinlock_t read_lock;
u8 *notification_buffer;/* to reassemble
fragmented notifications */
unsigned int nb_index;
- int write_used; /* number of non-empty
write buffers */
int transmitting;
spinlock_t write_lock;
struct mutex mutex;
--
2.1.4
[PATCH 3/4] cdc-acm: log message for serial state notification
Adds a similar log message to USB_CDC_NOTIFY_SERIAL_STATE as it is
already done with USB_CDC_NOTIFY_NETWORK_CONNECTION.
Signed-off-by: Tobias Herzog
---
drivers/usb/class/cdc-acm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index b99127e..2402b26 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -303,6 +303,8 @@ static void acm_process_notification(struct acm *acm,
unsigned char *buf)
}
newctrl = get_unaligned_le16(data);
+ dev_dbg(&acm->control->dev,
+ "%s - serial state: 0x%x\n", __func__, newctrl);
if (!acm->clocal && (acm->ctrlin & ~newctrl & ACM_CTRL_DCD)) {
dev_dbg(&acm->control->dev,
--
2.1.4
[PATCH 1/4] cdc-acm: reassemble fragmented notifications
USB devices may have very limitited endpoint packet sizes, so that
notifications can not be transferred within one single usb packet.
Reassembling of multiple packages may be necessary.
Signed-off-by: Tobias Herzog
---
drivers/usb/class/cdc-acm.c | 102 +++-
drivers/usb/class/cdc-acm.h | 2 +
2 files changed, 75 insertions(+), 29 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index e35b150..40714fe 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -282,39 +282,13 @@ static DEVICE_ATTR(iCountryCodeRelDate, S_IRUGO,
show_country_rel_date, NULL);
* Interrupt handlers for various ACM device responses
*/
-/* control interface reports status changes with "interrupt" transfers */
-static void acm_ctrl_irq(struct urb *urb)
+static void acm_process_notification(struct acm *acm, unsigned char *buf)
{
- struct acm *acm = urb->context;
- struct usb_cdc_notification *dr = urb->transfer_buffer;
- unsigned char *data;
int newctrl;
int difference;
- int retval;
- int status = urb->status;
+ struct usb_cdc_notification *dr = (struct usb_cdc_notification *)buf;
+ unsigned char *data = (unsigned char *)(dr + 1);
- switch (status) {
- case 0:
- /* success */
- break;
- case -ECONNRESET:
- case -ENOENT:
- case -ESHUTDOWN:
- /* this urb is terminated, clean up */
- dev_dbg(&acm->control->dev,
- "%s - urb shutting down with status: %d\n",
- __func__, status);
- return;
- default:
- dev_dbg(&acm->control->dev,
- "%s - nonzero urb status received: %d\n",
- __func__, status);
- goto exit;
- }
-
- usb_mark_last_busy(acm->dev);
-
- data = (unsigned char *)(dr + 1);
switch (dr->bNotificationType) {
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
dev_dbg(&acm->control->dev,
@@ -363,8 +337,74 @@ static void acm_ctrl_irq(struct urb *urb)
__func__,
dr->bNotificationType, dr->wIndex,
dr->wLength, data[0], data[1]);
+ }
+}
+
+/* control interface reports status changes with "interrupt" transfers */
+static void acm_ctrl_irq(struct urb *urb)
+{
+ struct acm *acm = urb->context;
+ struct usb_cdc_notification *dr = urb->transfer_buffer;
+ unsigned int current_size = urb->actual_length;
+ unsigned int expected_size, copy_size;
+ int retval;
+ int status = urb->status;
+
+ switch (status) {
+ case 0:
+ /* success */
break;
+ case -ECONNRESET:
+ case -ENOENT:
+ case -ESHUTDOWN:
+ /* this urb is terminated, clean up */
+ kfree(acm->notification_buffer);
+ acm->notification_buffer = NULL;
+ dev_dbg(&acm->control->dev,
+ "%s - urb shutting down with status: %d\n",
+ __func__, status);
+ return;
+ default:
+ dev_dbg(&acm->control->dev,
+ "%s - nonzero urb status received: %d\n",
+ __func__, status);
+ goto exit;
}
+
+ usb_mark_last_busy(acm->dev);
+
+ if (acm->notification_buffer)
+ dr = (struct usb_cdc_notification *)acm->notification_buffer;
+
+ /* assume the first package contains at least two bytes */
+ expected_size = dr->wLength + 8;
+
+ if (current_size < expected_size) {
+ /* notification is transmitted framented, reassemble */
+ if (!acm->notification_buffer) {
+ acm->notification_buffer =
+ kmalloc(expected_size, GFP_ATOMIC);
+ acm->nb_index = 0;
+ }
+
+ copy_size = min(current_size,
+ expected_size - acm->nb_index);
+
+ memcpy(&acm->notification_buffer[acm->nb_index],
+ urb->transfer_buffer, copy_size);
+ acm->nb_index += copy_size;
+ current_size = acm->nb_index;
+ }
+
+ if (current_size < expected_size)
+ goto exit;
+
+ /* notification complete */
+ acm_process_notification(acm, (unsigned char *)dr);
+
+ kfree(acm->notification_buffer);
+ acm->notification_buffer = NULL;
+
exit:
retval = usb_submit_urb(urb, GFP_ATOMIC);
if (retval && retval != -EPERM)
@@ -1488,6 +1528,8 @@ static int acm_probe(struct usb_interface *intf,
epctrl->bInterval ? epctrl->bInterval : 16);
acm->ctrlurb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
acm->ctrlurb->transfer_dma = acm->ctrl_d
[PATCH 2/4] cdc-acm: fix possible invalid access when processing notification
Notifications may only be 8 bytes so long. Accessing the 9th and
10th byte of unimplemented/unknown notifications may be insecure.
Also check the length of known notifications before accessing anything
behind the 8th byte.
Signed-off-by: Tobias Herzog
---
drivers/usb/class/cdc-acm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 40714fe..b99127e 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -296,6 +296,12 @@ static void acm_process_notification(struct acm *acm,
unsigned char *buf)
break;
case USB_CDC_NOTIFY_SERIAL_STATE:
+ if (dr->wLength != 2) {
+ dev_dbg(&acm->control->dev,
+ "%s - malformed serial state\n", __func__);
+ break;
+ }
+
newctrl = get_unaligned_le16(data);
if (!acm->clocal && (acm->ctrlin & ~newctrl & ACM_CTRL_DCD)) {
@@ -332,11 +338,10 @@ static void acm_process_notification(struct acm *acm,
unsigned char *buf)
default:
dev_dbg(&acm->control->dev,
- "%s - unknown notification %d received: index %d "
- "len %d data0 %d data1 %d\n",
+ "%s - unknown notification %d received: index %d len
%d\n",
__func__,
dr->bNotificationType, dr->wIndex,
- dr->wLength, data[0], data[1]);
+ dr->wLength);
}
}
--
2.1.4
Re: [PATCH] PCI: aardvark: Remove msi-controller dt node probing
On Tue, Mar 14, 2017 at 02:30:05PM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 14, 2017 at 12:08:51PM -0700, Stephen Boyd wrote:
> > This code assigns variables that are never used. Remove them.
> >
> > Reported-by: Srinivas Kandagatla
> > Cc: Thomas Petazzoni
> > Signed-off-by: Stephen Boyd
>
> I love removing unused code! Applied to pci/host-aardvark for v4.12,
> thanks!
Actually, I applied Thomas' series [1], which does some additional
cleanup and also removes this same code. So I'll just drop this one
since it's redundant. Thanks again and sorry for my confusion.
[1] https://patchwork.ozlabs.org/patch/733572/
> > ---
> > drivers/pci/host/pci-aardvark.c | 8
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-aardvark.c
> > b/drivers/pci/host/pci-aardvark.c
> > index 4fce494271cc..56e1aead65fc 100644
> > --- a/drivers/pci/host/pci-aardvark.c
> > +++ b/drivers/pci/host/pci-aardvark.c
> > @@ -917,8 +917,6 @@ static int advk_pcie_probe(struct platform_device *pdev)
> > struct advk_pcie *pcie;
> > struct resource *res;
> > struct pci_bus *bus, *child;
> > - struct msi_controller *msi;
> > - struct device_node *msi_node;
> > int ret, irq;
> >
> > pcie = devm_kzalloc(dev, sizeof(struct advk_pcie), GFP_KERNEL);
> > @@ -962,12 +960,6 @@ static int advk_pcie_probe(struct platform_device
> > *pdev)
> > return ret;
> > }
> >
> > - msi_node = of_parse_phandle(dev->of_node, "msi-parent", 0);
> > - if (msi_node)
> > - msi = of_pci_find_msi_chip_by_node(msi_node);
> > - else
> > - msi = NULL;
> > -
> > bus = pci_scan_root_bus_msi(dev, 0, &advk_pcie_ops,
> > pcie, &pcie->resources, &pcie->msi);
> > if (!bus) {
> > --
> > 2.10.0.297.gf6727b0
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[RFC 0/2] Basic divider clock
From: Markus Mayer This series contains a patch that was originally submitted by Mike Turquette in August 2013, but never merged.[1] Although I didn't see any comments rejecting it. We have been using this code for our STB platform for quite some time and wouldn't mind seeing it upstream. What are the current thoughts on merging this code? The patch is almost entirely how Mike submitted it originally. For the purposes of this RFC, I kept my modifications separate, to make it easier to see what is different from the original. I am expecting that my modifications would need to be squashed into the main patch with annotations in the commit message. There were trivial conflicts applying the original patch to 4.11-rc1. Those were entirely due to the patch context changing (clk_hw_unregister_divider() didn't exist back then) and not due to any incompatibilities with the patch itself. The other changes I made are listed and described in patch 2/2. [1] https://patchwork.kernel.org/patch/2848065/ Markus Mayer (1): clk: divider: modifications for 4.11 Mike Turquette (1): clk: dt: binding for basic divider clock .../devicetree/bindings/clock/divider-clock.txt| 90 +++ drivers/clk/clk-divider.c | 100 - include/linux/clk-provider.h | 1 + 3 files changed, 190 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/divider-clock.txt -- 2.7.4
[RFC 1/2] clk: dt: binding for basic divider clock
From: Mike Turquette
Devicetree binding for the basic clock divider, plus the setup function
to register the clock. Based on the existing fixed-clock binding.
Tero Kristo contributed helpful bug fixes to this patch.
Signed-off-by: Mike Turquette
Tested-by: Heiko Stuebner
Reviewed-by: Heiko Stuebner
Signed-off-by: Markus Mayer
---
.../devicetree/bindings/clock/divider-clock.txt| 90
drivers/clk/clk-divider.c | 98 +-
include/linux/clk-provider.h | 1 +
3 files changed, 188 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/divider-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/divider-clock.txt
b/Documentation/devicetree/bindings/clock/divider-clock.txt
new file mode 100644
index 000..ac80724
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/divider-clock.txt
@@ -0,0 +1,90 @@
+Binding for simple divider clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped adjustable clock rate divider that does not gate and has
+only one input clock or parent. By default the value programmed into
+the register is one less than the actual divisor value. E.g:
+
+register value actual divisor value
+0 1
+1 2
+2 3
+
+This assumption may be modified by the following optional properties:
+
+index-starts-at-one - valid divisor values start at 1, not the default
+of 0. E.g:
+register value actual divisor value
+1 1
+2 2
+3 3
+
+index-power-of-two - valid divisor values are powers of two. E.g:
+register value actual divisor value
+0 1
+1 2
+2 4
+
+index-allow-zero - same as index_one, but zero is divide-by-1. E.g:
+register value actual divisor value
+0 1
+1 1
+2 2
+
+Additionally a table of valid dividers may be supplied like so:
+
+ table = <4 0>, <8, 1>;
+
+where the first value in the pair is the divider and the second value is
+the programmed register bitfield.
+
+The binding must also provide the register to control the divider and
+the mask for the corresponding control bits. Optionally the number of
+bits to shift that mask, if necessary. If the shift value is missing it
+is the same as supplying a zero shift.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "divider-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link to phandle of parent clock
+- reg : base address for register controlling adjustable divider
+- bit-mask : arbitrary bitmask for programming the adjustable divider
+
+Optional properties:
+- clock-output-names : from common clock binding.
+- table : array of integer pairs defining divisors & bitfield values
+- bit-shift : number of bits to shift the bit-mask, defaults to
+ (ffs(mask) - 1) if not present
+- minimum-divider : min divisor for dividing the input clock rate, only
+ needed if the first divisor is offset from the default value
+- maximum-divider : max divisor for dividing the input clock rate, only
+ needed if the max divisor is less than (mask + 1).
+- index-starts-at-one : valid divisor programming starts at 1, not zero
+- index-power-of-two : valid divisor programming must be a power of two
+- index-allow-zero : implies index-one, and programming zero results in
+ divide-by-one
+- hiword-mask : lower half of the register programs the divider, upper
+ half of the register indicates bits that were updated in the lower
+ half
+
+Examples:
+ clock_foo: clock_foo@4a008100 {
+ compatible = "divider-clock";
+ #clock-cells = <0>;
+ clocks = <&clock_baz>;
+ reg = <0x4a008100 0x4>
+ mask = <0x3>
+ maximum-divider = <3>
+ };
+
+ clock_bar: clock_bar@4a008108 {
+ #clock-cells = <0>;
+ compatible = "divider-clock";
+ clocks = <&clock_foo>;
+ reg = <0x4a008108 0x4>;
+ mask = <0x1>;
+ shift = <0>;
+ table = < 4 0 >, < 8 1 >;
+ };
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 96386ff..df7290c 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -1,7 +1,7 @@
/*
* Copyright (C) 2011 Sascha Hauer, Pengutronix
* Copyright (C) 2011 Richard Zhao, Linaro
- * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd
+ * Copyright (C) 2011-2013 Mike Turquette, Linaro Ltd
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -17,6 +17,8 @@
#include
#include
#include
+#in
[RFC 2/2] clk: divider: modifications for 4.11
From: Markus Mayer
These changes were applied on top of the original commit[1]. Some
changes are more stylistic in nature, others were necessary due to
changes in the clock framework.
- make of_clk_get_div_table() static
- turn "u32 table_size" into "unsigned int table_size"
- wrap two over-long pr_err() lines
- change _register_divider() call and related code, since it is
returning a (struct clk_hw *) now instead of (struct clk *)
[1] https://patchwork.kernel.org/patch/2848065/
Signed-off-by: Markus Mayer
---
drivers/clk/clk-divider.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index df7290c..92605bc 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -617,10 +617,10 @@ EXPORT_SYMBOL_GPL(clk_hw_unregister_divider);
#ifdef CONFIG_OF
-struct clk_div_table *of_clk_get_div_table(struct device_node *node)
+static struct clk_div_table *of_clk_get_div_table(struct device_node *node)
{
int i;
- u32 table_size;
+ unsigned int table_size;
struct clk_div_table *table;
const __be32 *tablespec;
u32 val;
@@ -634,7 +634,8 @@ struct clk_div_table *of_clk_get_div_table(struct
device_node *node)
table = kzalloc(sizeof(struct clk_div_table) * table_size, GFP_KERNEL);
if (!table) {
- pr_err("%s: unable to allocate memory for %s table\n",
__func__, node->name);
+ pr_err("%s: unable to allocate memory for %s table\n", __func__,
+ node->name);
return NULL;
}
@@ -653,7 +654,7 @@ struct clk_div_table *of_clk_get_div_table(struct
device_node *node)
*/
void of_divider_clk_setup(struct device_node *node)
{
- struct clk *clk;
+ struct clk_hw *hw;
const char *clk_name = node->name;
void __iomem *reg;
const char *parent_name;
@@ -673,7 +674,8 @@ void of_divider_clk_setup(struct device_node *node)
}
if (of_property_read_u32(node, "bit-mask", &mask)) {
- pr_err("%s: missing bit-mask property for %s\n", __func__,
node->name);
+ pr_err("%s: missing bit-mask property for %s\n", __func__,
+ node->name);
return;
}
@@ -699,11 +701,11 @@ void of_divider_clk_setup(struct device_node *node)
if (IS_ERR(table))
return;
- clk = _register_divider(NULL, clk_name, parent_name, 0, reg, shift,
+ hw = _register_divider(NULL, clk_name, parent_name, 0, reg, shift,
mask, clk_divider_flags, table, NULL);
- if (!IS_ERR(clk))
- of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ if (!IS_ERR(hw))
+ of_clk_add_provider(node, of_clk_src_simple_get, hw->clk);
}
EXPORT_SYMBOL_GPL(of_divider_clk_setup);
CLK_OF_DECLARE(divider_clk, "divider-clock", of_divider_clk_setup);
--
2.7.4
Re: [PATCH v3 3/7] xen/9pfs: introduce Xen 9pfs transport driver
On Tue, 14 Mar 2017, Juergen Gross wrote:
> On 14/03/17 00:50, Stefano Stabellini wrote:
> > Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
> > register as a xenbus driver and add struct p9_trans_module to register
> > as v9fs driver.
> >
> > All functions are empty stubs for now.
> >
> > Signed-off-by: Stefano Stabellini
> > Reviewed-by: Boris Ostrovsky
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen
> > CC: Ron Minnich
> > CC: Latchesar Ionkov
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> > net/9p/trans_xen.c | 125
> > +
> > 1 file changed, 125 insertions(+)
> > create mode 100644 net/9p/trans_xen.c
> >
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > new file mode 100644
> > index 000..f072876
> > --- /dev/null
> > +++ b/net/9p/trans_xen.c
>
> > +static struct p9_trans_module p9_xen_trans = {
> > + .name = "xen",
> > + .maxsize = (1 << (XEN_9PFS_RING_ORDER + XEN_PAGE_SHIFT)),
>
> I think you can remove the outer brackets.
OK
Re: [PATCH] PCI: aardvark: Remove msi-controller dt node probing
Hello, On Tue, 14 Mar 2017 14:30:05 -0500, Bjorn Helgaas wrote: > On Tue, Mar 14, 2017 at 12:08:51PM -0700, Stephen Boyd wrote: > > This code assigns variables that are never used. Remove them. > > > > Reported-by: Srinivas Kandagatla > > Cc: Thomas Petazzoni > > Signed-off-by: Stephen Boyd > > I love removing unused code! Applied to pci/host-aardvark for v4.12, > thanks! Why? I have already sent a patch that also does this (and much more!) a number of times already, and it has never been applied. See: [PATCH v3 1/3] pci: pci-aardvark: move to MSI handling using generic MSI support v1 on September 1st, 2016 v2 on December 23th, 2016 v3 on February 28th, 2017 Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
Le mardi 14 mars 2017 à 15:47 +0100, Benjamin Gaignard a écrit : > Should we use /devi/ion/$heap instead of /dev/ion_$heap ? > I think it would be easier for user to look into one directory rather > then in whole /dev to find the heaps > > > is that we don't have to worry about a limit of 32 possible > > heaps per system (32-bit heap id allocation field). But dealing > > with an ioctl seems easier than names. Userspace might be less > > likely to hardcode random id numbers vs. names as well. > > In the futur I think that heap type will be replaced by a "get caps" > ioctl which will > describe heap capabilities. At least that is my understanding of > kernel part > of "unix memory allocator" project I think what we really need from userspace point of view, is the ability to find a compatible heap for a set of drivers. And this without specific knowledge of the drivers. Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH RFC] KVM: VMX: drop vmm_exclusive module parameter
2017-03-10 12:47+0100, David Hildenbrand:
> vmm_exclusive=0 leads to KVM setting X86_CR4_VMXE always and calling
> VMXON only when the vcpu is loaded. X86_CR4_VMXE is used as an
> indication in cpu_emergency_vmxoff() (called on kdump) if VMXOFF has to be
> called. This is obviously not the case if both are used independtly.
> Calling VMXOFF without a previous VMXON will result in an exception.
>
> In addition, X86_CR4_VMXE is used as a mean to test if VMX is already in
> use by another VMM in hardware_enable(). So there can't really be
> co-existance. If the other VMM is prepared for co-existance and does a
> similar check, only one VMM can exist. If the other VMM is not prepared
> and blindly sets/clears X86_CR4_VMXE, we will get inconsistencies with
> X86_CR4_VMXE.
>
> As we also had bug reports related to clearing of vmcs with vmm_exclusive=0
> this seems to be pretty much untested. So let's better drop it.
Totally,
Reviewed-by: Radim Krčmář
> While at it, directly move setting/clearing X86_CR4_VMXE into
> kvm_cpu_vmxon/off.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/x86/kvm/vmx.c | 38 +++---
> 1 file changed, 7 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 283aa86..bbbfe12 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -84,9 +84,6 @@ module_param_named(eptad, enable_ept_ad_bits, bool,
> S_IRUGO);
> static bool __read_mostly emulate_invalid_guest_state = true;
> module_param(emulate_invalid_guest_state, bool, S_IRUGO);
>
> -static bool __read_mostly vmm_exclusive = 1;
> -module_param(vmm_exclusive, bool, S_IRUGO);
> -
> static bool __read_mostly fasteoi = 1;
> module_param(fasteoi, bool, S_IRUGO);
>
> @@ -914,8 +911,6 @@ static void nested_release_page_clean(struct page *page)
>
> static unsigned long nested_ept_get_cr3(struct kvm_vcpu *vcpu);
> static u64 construct_eptp(unsigned long root_hpa);
> -static void kvm_cpu_vmxon(u64 addr);
> -static void kvm_cpu_vmxoff(void);
> static bool vmx_xsaves_supported(void);
> static int vmx_set_tss_addr(struct kvm *kvm, unsigned int addr);
> static void vmx_set_segment(struct kvm_vcpu *vcpu,
> @@ -2235,15 +2230,10 @@ static void decache_tsc_multiplier(struct vcpu_vmx
> *vmx)
> static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> {
> struct vcpu_vmx *vmx = to_vmx(vcpu);
> - u64 phys_addr = __pa(per_cpu(vmxarea, cpu));
> bool already_loaded = vmx->loaded_vmcs->cpu == cpu;
>
> - if (!vmm_exclusive)
> - kvm_cpu_vmxon(phys_addr);
> - else if (!already_loaded)
> - loaded_vmcs_clear(vmx->loaded_vmcs);
> -
> if (!already_loaded) {
> + loaded_vmcs_clear(vmx->loaded_vmcs);
> local_irq_disable();
> crash_disable_local_vmclear(cpu);
>
> @@ -2321,11 +2311,6 @@ static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
> vmx_vcpu_pi_put(vcpu);
>
> __vmx_load_host_state(to_vmx(vcpu));
> - if (!vmm_exclusive) {
> - __loaded_vmcs_clear(to_vmx(vcpu)->loaded_vmcs);
> - vcpu->cpu = -1;
> - kvm_cpu_vmxoff();
> - }
> }
>
> static void vmx_decache_cr0_guest_bits(struct kvm_vcpu *vcpu);
> @@ -3416,6 +3401,7 @@ static __init int vmx_disabled_by_bios(void)
>
> static void kvm_cpu_vmxon(u64 addr)
> {
> + cr4_set_bits(X86_CR4_VMXE);
> intel_pt_handle_vmx(1);
>
> asm volatile (ASM_VMX_VMXON_RAX
> @@ -3458,12 +3444,8 @@ static int hardware_enable(void)
> /* enable and lock */
> wrmsrl(MSR_IA32_FEATURE_CONTROL, old | test_bits);
> }
> - cr4_set_bits(X86_CR4_VMXE);
> -
> - if (vmm_exclusive) {
> - kvm_cpu_vmxon(phys_addr);
> - ept_sync_global();
> - }
> + kvm_cpu_vmxon(phys_addr);
> + ept_sync_global();
>
> native_store_gdt(this_cpu_ptr(&host_gdt));
>
> @@ -3489,15 +3471,13 @@ static void kvm_cpu_vmxoff(void)
> asm volatile (__ex(ASM_VMX_VMXOFF) : : : "cc");
>
> intel_pt_handle_vmx(0);
> + cr4_clear_bits(X86_CR4_VMXE);
> }
>
> static void hardware_disable(void)
> {
> - if (vmm_exclusive) {
> - vmclear_local_loaded_vmcss();
> - kvm_cpu_vmxoff();
> - }
> - cr4_clear_bits(X86_CR4_VMXE);
> + vmclear_local_loaded_vmcss();
> + kvm_cpu_vmxoff();
> }
>
> static __init int adjust_vmx_controls(u32 ctl_min, u32 ctl_opt,
> @@ -9228,11 +9208,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm
> *kvm, unsigned int id)
> vmx->loaded_vmcs->shadow_vmcs = NULL;
> if (!vmx->loaded_vmcs->vmcs)
> goto free_msrs;
> - if (!vmm_exclusive)
> - kvm_cpu_vmxon(__pa(per_cpu(vmxarea, raw_smp_processor_id(;
> loaded_vmcs_init(vmx->loaded_vmcs);
> - if (!vmm_exclusive)
> - kvm_cpu_vmxoff();
>
> cpu = get_cpu();
> vmx_vcpu_load(&vmx->vcpu, cpu);
> --
> 2.9.3
>
Re: [RFC][PATCH] dma-buf: Introduce dma-buf test module
On 03/14/2017 01:13 PM, Daniel Vetter wrote:
> On Tue, Mar 14, 2017 at 01:04:19PM -0700, Laura Abbott wrote:
>>
>> dma-buf is designed to share buffers. Sharing means that there needs to
>> be another subsystem to accept those buffers. Introduce a simple test
>> module to act as a dummy system to accept dma_bufs from elsewhere. The
>> goal is to provide a very simple interface to validate exported buffers
>> do something reasonable. This is based on ion_test.c that existed for
>> the Ion framework.
>>
>> Signed-off-by: Laura Abbott
>> ---
>> This is basically a drop in of what was available as
>> drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
>> parts it might be useful as a more general test module. RFC mostly
>> to see if this is generally useful or not.
>
> We already have a test dma-buf driver, which also handles reservation
> objects and can create fences to provoke signalling races an all kinds of
> other fun. It's drivers/gpu/drm/vgem.
>
> If there's anything missing in there, patches very much welcome.
> -Daniel
>
Thanks for that pointer. It certainly looks more complete vs. allocating
a platform_device. I'll look and see if there's anything that needs
extension. Plus this means I can probably delete more code from Ion (woo)
Thanks,
Laura
>> ---
>> drivers/dma-buf/Kconfig | 9 ++
>> drivers/dma-buf/Makefile | 1 +
>> drivers/dma-buf/dma-buf-test.c| 309
>> ++
>> include/uapi/linux/dma_buf_test.h | 67 +
>> 4 files changed, 386 insertions(+)
>> create mode 100644 drivers/dma-buf/dma-buf-test.c
>> create mode 100644 include/uapi/linux/dma_buf_test.h
>>
>> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
>> index ed3b785..8b3fdb1 100644
>> --- a/drivers/dma-buf/Kconfig
>> +++ b/drivers/dma-buf/Kconfig
>> @@ -30,4 +30,13 @@ config SW_SYNC
>>WARNING: improper use of this can result in deadlocking kernel
>>drivers from userspace. Intended for test and debug only.
>>
>> +config DMA_BUF_TEST
>> +bool "Test module for dma-buf"
>> +default n
>> +---help---
>> + A test module to validate dma_buf APIs. This should not be
>> + enabled for general use.
>> +
>> + Say N here unless you know you want this.
>> +
>> endmenu
>> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
>> index c33bf88..5029608 100644
>> --- a/drivers/dma-buf/Makefile
>> +++ b/drivers/dma-buf/Makefile
>> @@ -1,3 +1,4 @@
>> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
>> obj-$(CONFIG_SYNC_FILE) += sync_file.o
>> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
>> +obj-$(CONFIG_DMA_BUF_TEST) += dma-buf-test.o
>> diff --git a/drivers/dma-buf/dma-buf-test.c b/drivers/dma-buf/dma-buf-test.c
>> new file mode 100644
>> index 000..3af131c
>> --- /dev/null
>> +++ b/drivers/dma-buf/dma-buf-test.c
>> @@ -0,0 +1,309 @@
>> +/*
>> + * Copyright (C) 2013 Google, Inc.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License versdma_buf 2, as published by the Free Software Foundatdma_buf,
>> and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#define pr_fmt(fmt) "dma-buf-test: " fmt
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +struct dma_buf_test_device {
>> +struct miscdevice misc;
>> +};
>> +
>> +struct dma_buf_test_data {
>> +struct dma_buf *dma_buf;
>> +struct device *dev;
>> +};
>> +
>> +static int dma_buf_handle_test_dma(struct device *dev, struct dma_buf
>> *dma_buf,
>> + void __user *ptr, size_t offset, size_t size,
>> + bool write)
>> +{
>> +int ret = 0;
>> +struct dma_buf_attachment *attach;
>> +struct sg_table *table;
>> +pgprot_t pgprot = pgprot_writecombine(PAGE_KERNEL);
>> +enum dma_data_direction dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
>> +struct sg_page_iter sg_iter;
>> +unsigned long offset_page;
>> +
>> +attach = dma_buf_attach(dma_buf, dev);
>> +if (IS_ERR(attach))
>> +return PTR_ERR(attach);
>> +
>> +table = dma_buf_map_attachment(attach, dir);
>> +if (IS_ERR(table))
>> +return PTR_ERR(table);
>> +
>> +offset_page = offset >> PAGE_SHIFT;
>> +offset %= PAGE_SIZE;
>> +
>> +for_each_sg_page(table->sgl, &sg_iter, table->nents, offset_page) {
>> +struct page *page = sg_page_iter_page(&sg_iter);
>> +void *vaddr = vmap(&page, 1, VM_MAP, pgprot);
>>
Re: [PATCH v3 6/7] xen/9pfs: receive responses
On Tue, 14 Mar 2017, Juergen Gross wrote:
> On 14/03/17 00:50, Stefano Stabellini wrote:
> > Upon receiving a notification from the backend, schedule the
> > p9_xen_response work_struct. p9_xen_response checks if any responses are
> > available, if so, it reads them one by one, calling p9_client_cb to send
> > them up to the 9p layer (p9_client_cb completes the request). Handle the
> > ring following the Xen 9pfs specification.
> >
> > Signed-off-by: Stefano Stabellini
> > Reviewed-by: Boris Ostrovsky
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen
> > CC: Ron Minnich
> > CC: Latchesar Ionkov
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> > net/9p/trans_xen.c | 55
> > ++
> > 1 file changed, 55 insertions(+)
> >
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > index b40bbcb..1a7eb52 100644
> > --- a/net/9p/trans_xen.c
> > +++ b/net/9p/trans_xen.c
> > @@ -168,6 +168,61 @@ static int p9_xen_request(struct p9_client *client,
> > struct p9_req_t *p9_req)
> >
> > static void p9_xen_response(struct work_struct *work)
> > {
> > + struct xen_9pfs_front_priv *priv;
> > + struct xen_9pfs_dataring *ring;
> > + RING_IDX cons, prod, masked_cons, masked_prod;
> > + struct xen_9pfs_header h;
> > + struct p9_req_t *req;
> > + int status;
> > +
> > + ring = container_of(work, struct xen_9pfs_dataring, work);
> > + priv = ring->priv;
> > +
> > + while (1) {
> > + cons = ring->intf->in_cons;
> > + prod = ring->intf->in_prod;
> > + virt_rmb();
> > +
> > + if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) <
> > sizeof(h)) {
> > + notify_remote_via_irq(ring->irq);
> > + return;
> > + }
> > +
> > + masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
> > + masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> > +
> > + /* First, read just the header */
> > + xen_9pfs_read_packet(ring->data.in,
> > + masked_prod, &masked_cons,
> > + XEN_9PFS_RING_SIZE, &h, sizeof(h));
> > +
> > + req = p9_tag_lookup(priv->client, h.tag);
> > + if (!req || req->status != REQ_STATUS_SENT) {
> > + dev_warn(&priv->dev->dev, "Wrong req tag=%x\n", h.tag);
> > + cons += h.size;
> > + virt_mb();
> > + ring->intf->in_cons = cons;
> > + continue;
> > + }
> > +
> > + memcpy(req->rc, &h, sizeof(h));
> > + req->rc->offset = 0;
> > +
> > + masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> > + /* Then, read the whole packet (including the header) */
> > + xen_9pfs_read_packet(ring->data.in,
> > + masked_prod, &masked_cons,
> > + XEN_9PFS_RING_SIZE, req->rc->sdata, h.size);
>
> Please align the parameters to the same column.
I am one of those heretics that use tabstop=4 :-)
I'll fix this though.
> > +
> > + virt_mb();
> > + cons += h.size;
> > + ring->intf->in_cons = cons;
> > +
> > + status = (req->status != REQ_STATUS_ERROR) ?
> > + REQ_STATUS_RCVD : REQ_STATUS_ERROR;
> > +
> > + p9_client_cb(priv->client, req, status);
> > + }
> > }
> >
> > static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
> >
>
>
> Juergen
>
Re: [PATCH 1/3] Staging: ks7010: ks_*: Use preferred 'u8' kernel type over 'uint8_t'
On Tue, Mar 14, 2017 at 04:12:31PM +0100, Shiva Kerdel wrote: > Hello Tobin, > > I missed the other files because they did not show up using the checkpatch > script. > Next time I will do a recursive search through the files before committing > the changes to avoid this situation. > > Before I could replay on your message, I got notified of my patches already > been merged. I saw that :) > However, I am willing to check the other files if you like when I get home > and change them too if it's not already done yet. It's not a big issue, do it only if it pleases you. > > Finally it's hard to be descriptive about such changes since the title is > very self explaining to me, but I know, I am finding writing the git log to be the most challenging part of kernel development so far Good luck, Tobin.
Re: [PATCH] KVM: VMX: downgrade warning on unexpected exit code
2017-03-10 19:56+0100, Dmitry Vyukov:
> On Sun, Jan 15, 2017 at 8:18 PM, Dmitry Vyukov wrote:
> >> 2017-01-02 11:23+0100, Dmitry Vyukov:
> >>> Hello,
> >>>
> >>> I've got the following warning while running syzkaller fuzzer:
> >>>
> >>> WARNING: CPU: 2 PID: 13257 at arch/x86/kvm/vmx.c:8633
> >>> vmx_handle_exit+0x262b/0x38b0 arch/x86/kvm/vmx.c:8633
> >>> vmx: unexpected exit reason 0xb
> >>> CPU: 2 PID: 13257 Comm: syz-executor7 Not tainted 4.10.0-rc1+ #118
> >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
> >>> 01/01/2011
> >>> Call Trace:
> >>> __dump_stack lib/dump_stack.c:15 [inline]
> >>> dump_stack+0x292/0x3a2 lib/dump_stack.c:51
> >>> panic+0x1cb/0x3a9 kernel/panic.c:179
> >>> __warn+0x1c4/0x1e0 kernel/panic.c:539
> >>> warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:562
> >>> vmx_handle_exit+0x262b/0x38b0 arch/x86/kvm/vmx.c:8633
> >>> vcpu_enter_guest arch/x86/kvm/x86.c:6884 [inline]
> >>> vcpu_run arch/x86/kvm/x86.c:6943 [inline]
> >>> kvm_arch_vcpu_ioctl_run+0xf3d/0x45f0 arch/x86/kvm/x86.c:7101
> >>> kvm_vcpu_ioctl+0x673/0x1120
> >>> arch/x86/kvm/../../../virt/kvm/kvm_main.c:2569
> >>> vfs_ioctl fs/ioctl.c:43 [inline]
> >>> do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:683
> >>> SYSC_ioctl fs/ioctl.c:698 [inline]
> >>> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
> >>> entry_SYSCALL_64_fastpath+0x1f/0xc2
> >>> RIP: 0033:0x4438a9
> >>> RSP: 002b:7f935aa2fb58 EFLAGS: 0286 ORIG_RAX: 0010
> >>> RAX: ffda RBX: 0015 RCX: 004438a9
> >>> RDX: RSI: ae80 RDI: 0015
> >>> RBP: 006ddb30 R08: R09:
> >>> R10: R11: 0286 R12: 0070
> >>> R13: 0006 R14: 0015 R15: 20014000
> >>> Dumping ftrace buffer:
> >>>(ftrace buffer empty)
> >>> Kernel Offset: disabled
> >>>
> >>> Exit reason 0xb is GETSEC instruction. This does not look harmful as
> >>> it is handled as #UD. But I think we should print a single line
> >>> message regarding non-emulated instruction as in other cases, just to
> >>> not scare cloud admins and to make syzkaller ignore it.
> >>>
> >>> FTR, a raw reproducer is here:
> >>> https://gist.githubusercontent.com/dvyukov/c762f6ea04ebbba49cdee0a6caca31b4/raw/f21deb04cdc70ae74100c12447d71bb0cd2025c7/gistfile1.txt
> >>
> >> I can't reproduce -- maybe a nested bug, which will take a while to
> >> figure out. Still, host dump at that point is useless, so the change
> >> makes sense.
> >>
> >> A guest dump would be useful (e.g. I think that GETSEC should not exit
> >
> > Thanks!
> >
> > I had to disable dump_vmcs locally because it constantly produces tons
> > of output even when no bugs happen.
> > If you really-really need it, I can enable dump_vmcs and re-reproduce the
> > bug.
> >
> >
> >> if guest CR4.SMX is disabled), but just giving the error is about as
> >> good and we want something short and rate-limited if the message can be
> >> trigerred by a guest in production ...
> >> ---8<---
> >> We never needed the call trace and we better rate-limit if it can be
> >> triggered by a guest.
> >>
> >> Signed-off-by: Radim Krčmář
> >> ---
> >> arch/x86/kvm/vmx.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> >> index a236decb81e4..7cd606daa01e 100644
> >> --- a/arch/x86/kvm/vmx.c
> >> +++ b/arch/x86/kvm/vmx.c
> >> @@ -8595,7 +8595,8 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu)
> >> && kvm_vmx_exit_handlers[exit_reason])
> >> return kvm_vmx_exit_handlers[exit_reason](vcpu);
> >> else {
> >> - WARN_ONCE(1, "vmx: unexpected exit reason 0x%x\n",
> >> exit_reason);
> >> + vcpu_unimpl(vcpu, "vmx: unexpected exit reason 0x%x\n",
> >> + exit_reason);
> >> kvm_queue_exception(vcpu, UD_VECTOR);
> >> return 1;
> >> }
> >> --
> >> 2.11.0
> >>
>
> Was this ever merged? Still happens for me.
No, it was forgotten ... queued now,
Thanks
Re: [PATCH v15 6/9] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
On Sat, 11 Mar 2017, Kyle Huey wrote:
> static void init_intel_misc_features(struct cpuinfo_x86 *c)
> {
> u64 msr;
>
> + if (rdmsrl_safe(MSR_MISC_FEATURES_ENABLES, &msr))
> + return;
> +
> + msr = 0;
> + wrmsrl(MSR_MISC_FEATURES_ENABLES, msr);
> + this_cpu_write(msr_misc_features_shadow, msr);
> +
> if (!rdmsrl_safe(MSR_PLATFORM_INFO, &msr)) {
> if (msr & MSR_PLATFORM_INFO_CPUID_FAULT)
> set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
> }
>
> probe_xeon_phi_r3mwait(c);
The way you are doing it breaks the ring3 mwait feature because you
overwrite the R3MWAIT bit the first time you update the MSR on context
switch.
> }
What you really want is to fixup the r3mwait part:
static void probe_xeon_phi_r3mwait(c)
{
if (ring3mwait_disabled)
return;
set_cpu_cap(c, X86_FEATURE_RING3MWAIT);
this_cpu_or(msr_misc_features_shadow,
1UL << MSR_MISC_FEATURE_ENABLES_RING3MWAIT_BIT);
if (c == &boot_cpu_data)
ELF_HWCAP2 |= HWCAP2_RING3MWAIT;
}
and have a function for cpuid fault:
static void init_cpuid_fault(c)
{
if (rdmsrl_safe(MSR_PLATFORM_INFO, &msr))
return;
if ((msr & MSR_PLATFORM_INFO_CPUID_FAULT))
set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
}
and then do:
static void init_intel_misc_features(struct cpuinfo_x86 *c)
{
u64 msr;
if (rdmsrl_safe(MSR_MISC_FEATURES_ENABLES, &msr))
return;
/* Clear all MISC features */
this_cpu_write(msr_misc_features_shadow, 0);
/* Check the features and update the shadow control bits */
init_cpuid_fault(c);
probe_xeon_phi_r3mwait(c);
msr_write(MSR_MISC_FEATURE_ENABLES,
this_cpu_read(msr_misc_features_shadow);
}
Hmm?
Thanks,
tglx
Re: [PATCH] KVM: nVMX: don't reset kvm mmu twice
2017-03-12 00:53-0800, Wanpeng Li: > From: Wanpeng Li > > kvm mmu is reset once successfully loading CR3 as part of emulating vmentry > in nested_vmx_load_cr3(). We should not reset kvm mmu twice. > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Signed-off-by: Wanpeng Li > --- Queued, thanks. > arch/x86/kvm/vmx.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > index 98e82ee..bca8d7a 100644 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -10286,8 +10286,6 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, > struct vmcs12 *vmcs12, > entry_failure_code)) > return 1; > > - kvm_mmu_reset_context(vcpu); > - > if (!enable_ept) > vcpu->arch.walk_mmu->inject_page_fault = > vmx_inject_page_fault_nested; > > -- > 2.7.4 >
Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form
Krzysztof Kozlowski wrote: > On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote: >> Krzysztof Kozlowski wrote: >>> On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: Hello Krzysztof, I was wondering about the benefit of this. From a quick look these are all messages that end up in the kernel log / dmesg. IIRC %pK does nothing there, since dmest_restrict is supposed to be used to deny an unpriviliged user the access to the kernel log. Or am I missing something here? >>> >>> These are regular printks so depending on kernel options (e.g. dynamic >>> debug, drm.debug) these might be printed also in the console. Of course >>> we could argue then if access to one of the consoles is worth >>> securing. >> This here suggests otherwise. >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt#n388 >> >> I have not tested this, but IIRC %pK is not honored by the kernel >> logging infrastucture. That's why dmesg_restrict is there. >> >> Correct me if I'm wrong. > > The %pK will not help for dmesg or /proc/kmsg but it will help for > console (/dev/ttySACN, ttySN etc) because effectively it uses the same > vsprintf()/pointer() functions. Thanks for the explanation, I didn't know that there was a difference there. In that case, looks good to me. > As I said, we could argue whether securing console is worth... usually > attacker having access to it has also physical access to the machine so > everything gets easier... Still, putting %pK there certainly doesn't hurt. - Tobias > > Best regards, > Krzysztof > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [4.10][regression][PM] Oops pci_restore_msi_state() e1000e? (Re: [BUG] 4.11.0-rc1 panic on shutdown X61s)
This isn't just Lenovo, My Dell laptop experiences same problem, there is bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194801 Thanks, Shawn On 02/25/2017 04:53 AM, Shawn Starr wrote: Hello kernel devs, Hibernation appears broken for me in 4.10, I notice the e1000e does not resume on boot, and kernel shows why.. This kernel contains agd5f's 4.11/4.12-drm-next branches merged in. I am unsure if this is a result of the AMDGPU performing a bad hibernation (since it hangs when it finishes dumping pages to disk and doesn't reboot system when /sys/power/disk is set for 'reboot' mode.) otherwise this bug has been persistent in 4.10-rcX. Thanks, Shawn [ 912.256010] BUG: unable to handle kernel NULL pointer dereference at 003c [ 912.257227] IP: pci_restore_msi_state+0x1bd/0x270 [ 912.258218] PGD 0 [ 912.260182] Oops: [#1] SMP [ 912.261168] Modules linked in: ebtable_filter ebtables ip6table_filter ip6_tables bridge stp llc toshiba_acpi industrialio toshiba_haps hp_accel lis3lv02d input_polldev intel_rapl arc4 iwlmvm x86_pkg_temp_thermal intel_powerclamp dell_wmi coretemp iTCO_wdt vfat dell_laptop sparse_keymap kvm_intel fat mac80211 iTCO_vendor_support dell_smbios mei_wdt dcdbas dell_smm_hwmon ppdev kvm uvcvideo videobuf2_vmalloc snd_hda_codec_realtek snd_hda_codec_generic snd_usb_audio videobuf2_memops videobuf2_v4l2 irqbypass videobuf2_core snd_hda_codec_hdmi crct10dif_pclmul snd_soc_rt5640 crc32_pclmul snd_soc_rl6231 ghash_clmulni_intel snd_hda_intel snd_soc_core snd_hda_codec snd_usbmidi_lib snd_hda_core snd_compress snd_pcm_dmaengine ac97_bus iwlwifi intel_cstate intel_uncore videodev snd_hwdep intel_rapl_perf snd_seq [ 912.265654] media snd_rawmidi snd_seq_device cfg80211 snd_pcm snd_timer pcspkr ie31200_edac joydev snd video snd_soc_sst_acpi soundcore mei_me parport_pc edac_core elan_i2c mei parport snd_soc_sst_match i2c_designware_platform shpchp spi_pxa2xx_platform tpm_tis dw_dmac lpc_ich i2c_designware_core tpm_tis_core i2c_i801 tpm dell_smo8800 dell_rbtn rfkill wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc amdkfd amd_iommu_v2 amdgpu i2c_algo_bit drm_kms_helper ttm drm netconsole sdhci_pci sdhci_acpi sdhci crc32c_intel mmc_core serio_raw fjes i2c_hid e1000e ptp pps_core [ 912.269609] CPU: 2 PID: 867 Comm: NetworkManager Tainted: GW 4.10.0+ #1 [ 912.270919] Hardware name: Dell Inc. Precision M6800/05NG6V, BIOS A16 12/01/2015 [ 912.272242] task: 8f3fb7629d80 task.stack: b79243cec000 [ 912.273576] RIP: 0010:pci_restore_msi_state+0x1bd/0x270 [ 912.274916] RSP: 0018:b79243cef540 EFLAGS: 00010286 [ 912.276262] RAX: RBX: 8f3fe97f9000 RCX: [ 912.277623] RDX: 0080 RSI: 0246 RDI: 0246 [ 912.278990] RBP: b79243cef560 R08: 0002 R09: b79243cef50c [ 912.280359] R10: 00c8 R11: 8f3fecc00028 R12: [ 912.281735] R13: fffc R14: 8f3fe97f97e0 R15: 8f3fe97f90a0 [ 912.283114] FS: 7fb468d04940() GS:8f3fedc8() knlGS: [ 912.284506] CS: 0010 DS: ES: CR0: 80050033 [ 912.286248] CR2: 003c CR3: 0007f5881000 CR4: 001406a0 [ 912.287652] Call Trace: [ 912.289049] pci_restore_state.part.35+0x119/0x240 [ 912.290449] ? pci_restore_standard_config+0x40/0x40 [ 912.291840] pci_restore_state+0x18/0x20 [ 912.293224] pci_restore_standard_config+0x37/0x40 [ 912.294599] pci_pm_runtime_resume+0x46/0xa0 [ 912.295969] __rpm_callback+0xc2/0x200 [ 912.297337] ? ipv6_mc_down+0x6d/0x80 [ 912.298703] rpm_callback+0x5f/0x80 [ 912.300063] ? pci_restore_standard_config+0x40/0x40 [ 912.301423] rpm_resume+0x4a4/0x6b0 [ 912.302778] ? inetdev_event+0x3d/0x4e0 [ 912.304133] ? skb_dequeue+0x59/0x70 [ 912.305487] __pm_runtime_resume+0x4e/0x80 [ 912.306839] e1000e_open+0x59/0x450 [e1000e] [ 912.308175] __dev_open+0xc6/0x140 [ 912.309494] ? _raw_spin_unlock_bh+0x1a/0x20 [ 912.310801] __dev_change_flags+0x9d/0x160 [ 912.312103] dev_change_flags+0x29/0x60 [ 912.313391] do_setlink+0x338/0xc90 [ 912.314643] ? __nla_reserve+0x41/0x50 [ 912.315876] ? __nla_put+0x20/0x30 [ 912.317094] ? _raw_read_unlock_bh+0x20/0x30 [ 912.318296] ? inet6_fill_ifla6_attrs+0x494/0x4b0 [ 912.319481] ? inet6_fill_link_af+0x1a/0x30 [ 912.320651] ? rtnl_fill_ifinfo+0xb62/0x10c0 [ 912.321817] ? nla_parse+0x31/0x110 [ 912.323566] rtnl_newlink+0x7ac/0x8e0 [ 912.325432] ? security_capset+0x60/0x80 [ 912.327301] ? ns_capable_common+0x68/0x80 [ 912.329151] ? ns_capable+0x13/0x20 [ 912.330949] rtnetlink_rcv_msg+0xe6/0x210 [ 912.332712] ? __d_lookup+0x116/0x130 [ 912.334455] ? __kmalloc_node_track_caller+0x1f6/0x2b0 [ 912.336182] ? __alloc_skb+0x87/0x1c0 [ 912.337858] ? rtnl_newlink+0x8e0/0x8e0 [ 912.339504] netlink_rcv_skb+0xa4/0xc0 [ 912.341130] rtnetlink_rcv+0x28/0x30 [ 912.342719] netl
[PATCH] config: android-base: CONFIG_SYNC -> CONFIG_SYNC_FILE
Explicit sync was renamed to CONFIG_SYNC_FILE when it was destaged, but the Android config fragment still tries to use the old name. Signed-off-by: Greg Hackmann --- kernel/configs/android-base.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/configs/android-base.config b/kernel/configs/android-base.config index 26a06e09a5bd..1bbc0ca5b16e 100644 --- a/kernel/configs/android-base.config +++ b/kernel/configs/android-base.config @@ -140,7 +140,7 @@ CONFIG_SECURITY_SELINUX=y CONFIG_SETEND_EMULATION=y CONFIG_STAGING=y CONFIG_SWP_EMULATION=y -CONFIG_SYNC=y +CONFIG_SYNC_FILE=y CONFIG_TUN=y CONFIG_UNIX=y CONFIG_USB_GADGET=y -- 2.12.0.367.g23dc2f6d3c-goog
Re: [PATCH 2/4] misc: ds1682: Add OF device ID table
On Tue, Mar 14, 2017 at 4:16 PM, Javier Martinez Canillas
wrote:
> +static const struct of_device_id ds1682_of_match[] = {
> + { .compatible = "dallas,ds1682", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, ds1682_of_match);
> +
> static struct i2c_driver ds1682_driver = {
> .driver = {
> .name = "ds1682",
> + .of_match_table = of_match_ptr(ds1682_of_match),
> },
> .probe = ds1682_probe,
> .remove = ds1682_remove,
This will cause a warning if CONFIG_OF is disabled, since ds1682_of_match
becomes unused in this case. Please remove the of_match_ptr() around
the reference to ds1682_of_match.
Arnd
[tip:locking/urgent] futex: Fix potential use-after-free in FUTEX_REQUEUE_PI
Commit-ID: c236c8e95a3d395b0494e7108f0d41cf36ec107c
Gitweb: http://git.kernel.org/tip/c236c8e95a3d395b0494e7108f0d41cf36ec107c
Author: Peter Zijlstra
AuthorDate: Sat, 4 Mar 2017 10:27:18 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 14 Mar 2017 21:45:36 +0100
futex: Fix potential use-after-free in FUTEX_REQUEUE_PI
While working on the futex code, I stumbled over this potential
use-after-free scenario. Dmitry triggered it later with syzkaller.
pi_mutex is a pointer into pi_state, which we drop the reference on in
unqueue_me_pi(). So any access to that pointer after that is bad.
Since other sites already do rt_mutex_unlock() with hb->lock held, see
for example futex_lock_pi(), simply move the unlock before
unqueue_me_pi().
Reported-by: Dmitry Vyukov
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Darren Hart
Cc: juri.le...@arm.com
Cc: bige...@linutronix.de
Cc: xlp...@redhat.com
Cc: rost...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170304093558.801744...@infradead.org
Signed-off-by: Thomas Gleixner
---
kernel/futex.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 229a744..3a4775f 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2815,7 +2815,6 @@ static int futex_wait_requeue_pi(u32 __user *uaddr,
unsigned int flags,
{
struct hrtimer_sleeper timeout, *to = NULL;
struct rt_mutex_waiter rt_waiter;
- struct rt_mutex *pi_mutex = NULL;
struct futex_hash_bucket *hb;
union futex_key key2 = FUTEX_KEY_INIT;
struct futex_q q = futex_q_init;
@@ -2907,6 +2906,8 @@ static int futex_wait_requeue_pi(u32 __user *uaddr,
unsigned int flags,
spin_unlock(q.lock_ptr);
}
} else {
+ struct rt_mutex *pi_mutex;
+
/*
* We have been woken up by futex_unlock_pi(), a timeout, or a
* signal. futex_unlock_pi() will not destroy the lock_ptr nor
@@ -2930,18 +2931,19 @@ static int futex_wait_requeue_pi(u32 __user *uaddr,
unsigned int flags,
if (res)
ret = (res < 0) ? res : 0;
+ /*
+* If fixup_pi_state_owner() faulted and was unable to handle
+* the fault, unlock the rt_mutex and return the fault to
+* userspace.
+*/
+ if (ret && rt_mutex_owner(pi_mutex) == current)
+ rt_mutex_unlock(pi_mutex);
+
/* Unqueue and drop the lock. */
unqueue_me_pi(&q);
}
- /*
-* If fixup_pi_state_owner() faulted and was unable to handle the
-* fault, unlock the rt_mutex and return the fault to userspace.
-*/
- if (ret == -EFAULT) {
- if (pi_mutex && rt_mutex_owner(pi_mutex) == current)
- rt_mutex_unlock(pi_mutex);
- } else if (ret == -EINTR) {
+ if (ret == -EINTR) {
/*
* We've already been requeued, but cannot restart by calling
* futex_lock_pi() directly. We could restart this syscall, but
[tip:locking/urgent] futex: Add missing error handling to FUTEX_REQUEUE_PI
Commit-ID: 9bbb25afeb182502ca4f2c4f3f88af0681b34cae
Gitweb: http://git.kernel.org/tip/9bbb25afeb182502ca4f2c4f3f88af0681b34cae
Author: Peter Zijlstra
AuthorDate: Sat, 4 Mar 2017 10:27:19 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 14 Mar 2017 21:45:36 +0100
futex: Add missing error handling to FUTEX_REQUEUE_PI
Thomas spotted that fixup_pi_state_owner() can return errors and we
fail to unlock the rt_mutex in that case.
Reported-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Darren Hart
Cc: juri.le...@arm.com
Cc: bige...@linutronix.de
Cc: xlp...@redhat.com
Cc: rost...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170304093558.867401...@infradead.org
Signed-off-by: Thomas Gleixner
---
kernel/futex.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/futex.c b/kernel/futex.c
index 3a4775f..45858ec 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2898,6 +2898,8 @@ static int futex_wait_requeue_pi(u32 __user *uaddr,
unsigned int flags,
if (q.pi_state && (q.pi_state->owner != current)) {
spin_lock(q.lock_ptr);
ret = fixup_pi_state_owner(uaddr2, &q, current);
+ if (ret && rt_mutex_owner(&q.pi_state->pi_mutex) ==
current)
+ rt_mutex_unlock(&q.pi_state->pi_mutex);
/*
* Drop the reference to the pi state which
* the requeue_pi() code acquired for us.
Re: [PATCH] Kbuild: use cc-disable-warning consistently for maybe-uninitialized
On Tue, Mar 14, 2017 at 5:17 PM, Masahiro Yamada
wrote:
> Hi Arnd,
>
> 2017-01-14 0:40 GMT+09:00 Arnd Bergmann :
>> In commit a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning
>> for "make W=1""), I reverted another change that happened to fix a problem
>> with old compilers, and now we get this report again with old compilers
>> (prior to gcc-4.8) and GCOV enabled:
>>
>>cc1: warnings being treated as errors
>>drivers/gpu/drm/i915/intel_ringbuffer.c: In function
>> 'intel_ring_setup_status_page':
>>drivers/gpu/drm/i915/intel_ringbuffer.c:438: error: 'mmio.reg' may be
>> used uninitialized in this function
>>At top level:
cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
>>
>> The problem is that we turn off the warning conditionally in a number
>> of places as we should, but one of them does it unconditionally.
>> Instead, change it to call cc-disable-warning as we do elsewhere.
>>
>> The original patch that caused it was merged into linux-4.7, then
>> 4.8 removed the change and 4.9 brought it back, so we probably want
>> a backport to 4.9 once this is merged.
>>
>> Cc: sta...@vger.kernel.org
>> Fixes: a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning for "make
>> W=1"")
>> Fixes: e72e2dfe7c16 ("gcov: disable -Wmaybe-uninitialized warning")
>> Reported-by: kbuild test robot
>> Signed-off-by: Arnd Bergmann
>
>
> Applied to linux-kbuild/fixes.
Thanks!
> But, please let me ask one question.
>
> When I was checking your commit a76bcf557ef4,
> I noticed the following code:
>
>
> KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
>$(call cc-disable-warning,maybe-uninitialized,))
>
>
>
> It was not clear to me where this comes from
> because it is not the revert of Linus' commit.
>
>
> My best guess is:
> maybe-uninitialized was introduced by gcc 4.7,
> but only reliable for gcc 4.9 or later.
> So it should be disabled for gcc < 4.9
>
>
> Is this correct?
Yes. Actually this warning is by definition not reliable, but gcc-4.9
got a lot better than earlier versions, and the set of false positives
in 4.9 is different from the one in 4.8, which introduced the flag.
As most people have 4.9 or higher, it makes sense to address all
the warnings found by that version by modifying the code (either
fixing bugs or working around false positives), but to just disable it
for 4.8 and earlier.
In older compiler versions, -Wuninitialized controlled both the
"definitely uninitialized" and the "possibly uninitialized" warnings,
and also had a lot of false positives, but 4.7 and earlier also
prouce lots of other warnings. I try to get a warning free build with
4.8 and higher but don't even try for old versions at the moment,
though I have an idea for how we could do that too.
Arnd
Re: [PATCH 1/4] misc: tsl2550: Add OF device ID table
\
> static struct i2c_driver tsl2550_driver = {
> .driver = {
> .name = TSL2550_DRV_NAME,
> + .of_match_table = of_match_ptr(tsl2550_of_match),
> .pm = TSL2550_PM_OPS,
> },
Please drop the incorrect of_match_ptr().
Arnd
[tip:x86/urgent] x86/unwind: Fix last frame check for aligned function stacks
Commit-ID: 87a6b2975f0d340c75b7488d22d61d2f98fb8abf
Gitweb: http://git.kernel.org/tip/87a6b2975f0d340c75b7488d22d61d2f98fb8abf
Author: Josh Poimboeuf
AuthorDate: Mon, 13 Mar 2017 23:27:47 -0500
Committer: Thomas Gleixner
CommitDate: Tue, 14 Mar 2017 21:51:57 +0100
x86/unwind: Fix last frame check for aligned function stacks
Pavel Machek reported the following warning on x86-32:
WARNING: kernel stack frame pointer at f50cdf98 in swapper/2:0 has bad value
(null)
The warning is caused by the unwinder not realizing that it reached the
end of the stack, due to an unusual prologue which gcc sometimes
generates for aligned stacks. The prologue is based on a gcc feature
called the Dynamic Realign Argument Pointer (DRAP). It's almost always
enabled for aligned stacks when -maccumulate-outgoing-args isn't set.
This issue is similar to the one fixed by the following commit:
8023e0e2a48d ("x86/unwind: Adjust last frame check for aligned function
stacks")
... but that fix was specific to x86-64.
Make the fix more generic to cover x86-32 as well, and also ensure that
the return address referred to by the frame pointer is a copy of the
original return address.
Fixes: acb4608ad186 ("x86/unwind: Create stack frames for saved syscall
registers")
Reported-by: Pavel Machek
Signed-off-by: Josh Poimboeuf
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/50d4924db716c264b14f1633037385ec80bf89d2.1489465609.git.jpoim...@redhat.com
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/unwind_frame.c | 36 ++--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index 478d15d..0833926 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -82,19 +82,43 @@ static size_t regs_size(struct pt_regs *regs)
return sizeof(*regs);
}
+#ifdef CONFIG_X86_32
+#define GCC_REALIGN_WORDS 3
+#else
+#define GCC_REALIGN_WORDS 1
+#endif
+
static bool is_last_task_frame(struct unwind_state *state)
{
- unsigned long bp = (unsigned long)state->bp;
- unsigned long regs = (unsigned long)task_pt_regs(state->task);
+ unsigned long *last_bp = (unsigned long *)task_pt_regs(state->task) - 2;
+ unsigned long *aligned_bp = last_bp - GCC_REALIGN_WORDS;
/*
* We have to check for the last task frame at two different locations
* because gcc can occasionally decide to realign the stack pointer and
-* change the offset of the stack frame by a word in the prologue of a
-* function called by head/entry code.
+* change the offset of the stack frame in the prologue of a function
+* called by head/entry code. Examples:
+*
+* :
+* push %edi
+* lea0x8(%esp),%edi
+* and$0xfff8,%esp
+* pushl -0x4(%edi)
+* push %ebp
+* mov%esp,%ebp
+*
+* :
+* lea0x8(%rsp),%r10
+* and$0xfff0,%rsp
+* pushq -0x8(%r10)
+* push %rbp
+* mov%rsp,%rbp
+*
+* Note that after aligning the stack, it pushes a duplicate copy of
+* the return address before pushing the frame pointer.
*/
- return bp == regs - FRAME_HEADER_SIZE ||
- bp == regs - FRAME_HEADER_SIZE - sizeof(long);
+ return (state->bp == last_bp ||
+ (state->bp == aligned_bp && *(aligned_bp+1) == *(last_bp+1)));
}
/*
[PATCH linux v9 0/5] drivers: hwmon: Add On-Chip Controller driver
From: "Edward A. James" This patchset adds a hwmon driver to support the OCC (On-Chip Controller) on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The OCC is an embedded processor that provides real time power and thermal monitoring. The driver provides an interface on a BMC to poll OCC sensor data, set user power caps, and perform some basic OCC error handling. It interfaces with userspace through hwmon. The driver is currently functional only for the OCC on POWER8 chips. Communicating with the POWER9 OCC requries FSI support. since v8: * drop P9 sensors patch. This patch was mainly included to demonstrate why we abstracted out the sensor-specific code into the occ_p8 functions. However, since we haven't submitted the transfer protocol to the OCC for P9 yet, we shouldn't submit this unused P9 code yet. * fix string access in hwmon read_string() function. Thanks Guenter. * change parameter to const char ** in read_string() function to match upcoming hwmon code. Edward A. James (5): hwmon: Add core On-Chip Controller support for POWER CPUs hwmon: occ: Add sysfs interface hwmon: occ: Add I2C transport implementation for SCOM operations hwmon: occ: Add callbacks for parsing P8 OCC datastructures hwmon: occ: Add hwmon implementation for the P8 OCC Documentation/devicetree/bindings/hwmon/occ.txt | 13 + Documentation/hwmon/occ | 113 ++ MAINTAINERS | 7 + drivers/hwmon/Kconfig | 2 + drivers/hwmon/Makefile | 1 + drivers/hwmon/occ/Kconfig | 28 ++ drivers/hwmon/occ/Makefile | 3 + drivers/hwmon/occ/occ.c | 440 drivers/hwmon/occ/occ.h | 77 + drivers/hwmon/occ/occ_p8.c | 256 ++ drivers/hwmon/occ/occ_p8.h | 25 ++ drivers/hwmon/occ/occ_p8_i2c.c | 99 ++ drivers/hwmon/occ/occ_scom_i2c.c| 69 drivers/hwmon/occ/occ_scom_i2c.h| 21 ++ drivers/hwmon/occ/occ_sysfs.c | 253 ++ drivers/hwmon/occ/occ_sysfs.h | 25 ++ drivers/hwmon/occ/scom.h| 42 +++ 17 files changed, 1474 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt create mode 100644 Documentation/hwmon/occ create mode 100644 drivers/hwmon/occ/Kconfig create mode 100644 drivers/hwmon/occ/Makefile create mode 100644 drivers/hwmon/occ/occ.c create mode 100644 drivers/hwmon/occ/occ.h create mode 100644 drivers/hwmon/occ/occ_p8.c create mode 100644 drivers/hwmon/occ/occ_p8.h create mode 100644 drivers/hwmon/occ/occ_p8_i2c.c create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h create mode 100644 drivers/hwmon/occ/occ_sysfs.c create mode 100644 drivers/hwmon/occ/occ_sysfs.h create mode 100644 drivers/hwmon/occ/scom.h -- 1.8.3.1
[PATCH linux v9 2/5] hwmon: occ: Add sysfs interface
From: "Edward A. James"
Add a generic mechanism to expose the sensors provided by the OCC in
sysfs.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
Documentation/hwmon/occ | 62 +++
drivers/hwmon/occ/Makefile| 2 +-
drivers/hwmon/occ/occ_sysfs.c | 253 ++
drivers/hwmon/occ/occ_sysfs.h | 25 +
4 files changed, 341 insertions(+), 1 deletion(-)
create mode 100644 drivers/hwmon/occ/occ_sysfs.c
create mode 100644 drivers/hwmon/occ/occ_sysfs.h
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index d1c863b..580af26 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -27,6 +27,68 @@ Currently, all versions of the OCC support four types of
sensor data: power,
temperature, frequency, and "caps," which indicate limits and thresholds used
internally on the OCC.
+sysfs Entries
+-
+
+The OCC driver uses the hwmon sysfs framework to provide data to userspace.
+
+The driver exports a number of sysfs files for each type of sensor. The
+sensor-specific files vary depending on the processor type, though many of the
+attributes are common for both the POWER8 and POWER9.
+
+The hwmon interface cannot define every type of sensor that may be used.
+Therefore, the frequency sensor on the OCC uses the "input" type sensor defined
+by the hwmon interface, rather than defining a new type of custom sensor.
+
+Below are detailed the names and meaning of each sensor file for both types of
+processors. All sensors are read-only unless otherwise specified. indicates
+the hwmon index. sensor id indicates the unique internal OCC identifer. Please
+see the POWER OCC specification for details on all these sensor values.
+
+frequency:
+ all processors:
+ in_input - frequency value
+ in_label - sensor id
+temperature:
+ POWER8:
+ temp_input - temperature value
+ temp_label - sensor id
+ POWER9 (in addition to above):
+ temp_type - FRU type
+
+power:
+ POWER8:
+ power_input - power value
+ power_label - sensor id
+ power_average - accumulator
+ power_average_interval - update tag (number of samples in
+ accumulator)
+ POWER9:
+ power_input - power value
+ power_label - sensor id
+ power_average_min - accumulator[0]
+ power_average_max - accumulator[1] (64 bits total)
+ power_average_interval - update tag
+ power_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+ POWER8:
+ power_cap - current powercap
+ power_cap_max - max powercap
+ power_cap_min - min powercap
+ power_max - normal powercap
+ power_alarm - user powercap, r/w
+ POWER9:
+ power_cap_alarm - user powercap source
+
+The driver also provides two sysfs entries through hwmon to better
+control the driver and monitor the master OCC. Though there may be multiple
+OCCs present on the system, these two files are only present for the "master"
+OCC.
+ name - read the name of the driver
+ update_interval - read or write the minimum interval for polling the
+ OCC.
+
BMC - Host Communications
-
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 3ed79a5..67b5367 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o
+obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o
diff --git a/drivers/hwmon/occ/occ_sysfs.c b/drivers/hwmon/occ/occ_sysfs.c
new file mode 100644
index 000..50b20e2
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -0,0 +1,253 @@
+/*
+ * occ_sysfs.c - OCC sysfs interface
+ *
+ * This file contains the methods and data structures for implementing the OCC
+ * hwmon sysfs entries.
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#define OCC_HWMON_NAME_LENGTH 32
+
+struct occ_sysfs {
+ struct device *dev;
+ struct occ *occ;
+
+ char label_buffer[OCC_HWMON_NAME_LENGTH + 1];
+ char hwmon_name[OCC_HWMON_NAME_LENGTH + 1];
+ const u32 *sensor_hwmon_configs;
+ struct hwmon_channel_info **occ_sensors;
+ struct hwmon_chip_info occ_info;
+ u16 user_powercap;
+};
+
+static int occ_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channe
[PATCH linux v9 4/5] hwmon: occ: Add callbacks for parsing P8 OCC datastructures
From: "Edward A. James"
Add functions to parse the data structures that are specific to the OCC
on the POWER8 processor. These are the sensor data structures, including
temperature, frequency, power, and "caps."
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
Documentation/hwmon/occ| 9 ++
drivers/hwmon/occ/Makefile | 2 +-
drivers/hwmon/occ/occ_p8.c | 256 +
drivers/hwmon/occ/occ_p8.h | 25 +
4 files changed, 291 insertions(+), 1 deletion(-)
create mode 100644 drivers/hwmon/occ/occ_p8.c
create mode 100644 drivers/hwmon/occ/occ_p8.h
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index 580af26..4ec8842 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -27,6 +27,15 @@ Currently, all versions of the OCC support four types of
sensor data: power,
temperature, frequency, and "caps," which indicate limits and thresholds used
internally on the OCC.
+The format for the POWER8 OCC sensor data can be found in the P8 OCC
+specification:
+github.com/open-power/docs/blob/master/occ/OCC_OpenPwr_FW_Interfaces.pdf
+This document provides the details of the OCC sensors: power, frequency,
+temperature, and caps. These sensor formats are specific to the POWER8 OCC. A
+number of data structures, such as command format, response headers, and the
+like, are also defined in this specification, and are common to both POWER8 and
+POWER9 OCCs.
+
sysfs Entries
-
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 9cc36e7..f59cca4 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o occ_scom_i2c.o
+obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o occ_scom_i2c.o occ_p8.o
diff --git a/drivers/hwmon/occ/occ_p8.c b/drivers/hwmon/occ/occ_p8.c
new file mode 100644
index 000..ae8b453
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p8.c
@@ -0,0 +1,256 @@
+/*
+ * occ_p8.c - OCC hwmon driver
+ *
+ * This file contains the Power8-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "occ.h"
+#include "occ_p8.h"
+
+/* P8 OCC sensor data format */
+struct p8_occ_sensor {
+ u16 sensor_id;
+ u16 value;
+};
+
+struct p8_power_sensor {
+ u16 sensor_id;
+ u32 update_tag;
+ u32 accumulator;
+ u16 value;
+};
+
+struct p8_caps_sensor {
+ u16 curr_powercap;
+ u16 curr_powerreading;
+ u16 norm_powercap;
+ u16 max_powercap;
+ u16 min_powercap;
+ u16 user_powerlimit;
+};
+
+/* value, sensor_id */
+#define FREQ_SENSOR_CONFIG (HWMON_I_INPUT | HWMON_I_LABEL)
+#define TEMP_SENSOR_CONFIG (HWMON_T_INPUT | HWMON_T_LABEL)
+
+/* value, sensor_id, accumulator, update_tag */
+#define POWER_SENSOR_CONFIG\
+( \
+ HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE | \
+ HWMON_P_AVERAGE_INTERVAL\
+)
+
+/* curr_powercap, max_powercap, min_powercap, norm_powercap, user_powerlimit */
+#define CAPS_SENSOR_CONFIG \
+( \
+ HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX | \
+ HWMON_P_ALARM \
+)
+
+static const u32 p8_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+ FREQ_SENSOR_CONFIG,
+ TEMP_SENSOR_CONFIG,
+ POWER_SENSOR_CONFIG,
+ CAPS_SENSOR_CONFIG,
+};
+
+void p8_parse_sensor(u8 *data, void *sensor, int sensor_type, int off,
+int snum)
+{
+ switch (sensor_type) {
+ case FREQ:
+ case TEMP:
+ {
+ struct p8_occ_sensor *os =
+ &(((struct p8_occ_sensor *)sensor)[snum]);
+
+ os->sensor_id = be16_to_cpu(get_unaligned((u16 *)&data[off]));
+ os->value = be16_to_cpu(get_unaligned((u16 *)&data[off + 2]));
+ }
+ break;
+ case POWER:
+ {
+ struct p8_power_sensor *ps =
+ &(((struct p8_power_sensor *)sensor)[snum]);
+
+ ps->sensor_id = be16_to_cpu(get_unaligned((u16 *)&data[off]));
+ ps->update_tag =
+ be32_to_cpu(get_unaligned((u32 *)&data[off + 2]));
+ ps->accumulator =
+ be32_to_cpu(get_unaligned((u32 *)&data[off + 6]));
+ p
[PATCH linux v9 5/5] hwmon: occ: Add hwmon implementation for the P8 OCC
From: "Edward A. James"
Add code to tie the hwmon sysfs code and the POWER8 OCC code together,
as well as probe the entire driver from the I2C bus. I2C is the
communication method between the BMC and the P8 OCC.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/hwmon/occ.txt | 13
drivers/hwmon/occ/Kconfig | 15
drivers/hwmon/occ/Makefile | 4 +-
drivers/hwmon/occ/occ_p8_i2c.c | 99 +
4 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
create mode 100644 drivers/hwmon/occ/occ_p8_i2c.c
diff --git a/Documentation/devicetree/bindings/hwmon/occ.txt
b/Documentation/devicetree/bindings/hwmon/occ.txt
new file mode 100644
index 000..b0d2b36
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/occ.txt
@@ -0,0 +1,13 @@
+HWMON I2C driver for IBM POWER CPU OCC (On Chip Controller)
+
+Required properties:
+ - compatible: must be "ibm,p8-occ-i2c"
+ - reg: physical address
+
+Example:
+i2c3: i2c-bus@100 {
+ occ@50 {
+ compatible = "ibm,p8-occ-i2c";
+ reg = <0x50>;
+ };
+};
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
index 61be588..d521720 100644
--- a/drivers/hwmon/occ/Kconfig
+++ b/drivers/hwmon/occ/Kconfig
@@ -11,3 +11,18 @@ menuconfig SENSORS_IBM_OCC
Generally this is used by management controllers such as a BMC
on an OpenPower system.
+
+if SENSORS_IBM_OCC
+
+config SENSORS_IBM_OCC_P8_I2C
+ tristate "POWER8 OCC hwmon support"
+ depends on I2C
+ help
+ Provide a hwmon sysfs interface for the POWER8 On-Chip Controller,
+ exposing temperature, frequency and power measurements. This
+ interface runs on the service processor, not the POWER CPU.
+
+ This driver can also be built as a module. If so, the module will be
+ called hwmon_occ_p8.
+
+endif
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index f59cca4..864b044 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1,3 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o occ_scom_i2c.o occ_p8.o
+obj-$(CONFIG_SENSORS_IBM_OCC_P8_I2C) += hwmon_occ_p8.o
+
+hwmon_occ_p8-objs := occ.o occ_sysfs.o occ_scom_i2c.o occ_p8.o occ_p8_i2c.o
diff --git a/drivers/hwmon/occ/occ_p8_i2c.c b/drivers/hwmon/occ/occ_p8_i2c.c
new file mode 100644
index 000..2b4f6dd
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p8_i2c.c
@@ -0,0 +1,99 @@
+/*
+ * occ_p8_i2c.c - hwmon OCC driver
+ *
+ * This file contains the i2c layer for accessing the P8 OCC over i2c bus.
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "occ_p8.h"
+#include "occ_scom_i2c.h"
+#include "occ_sysfs.h"
+#include "scom.h"
+
+#define OCC_P8_I2C_NAME"p8-occ-i2c"
+
+int p8_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ /* P8 i2c slave requires scom address to be shifted by 1 */
+ address = address << 1;
+
+ return occ_i2c_getscom(bus, address, data);
+}
+
+int p8_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+ /* P8 i2c slave requires scom address to be shifted by 1 */
+ address = address << 1;
+
+ return occ_i2c_putscom(bus, address, data0, data1);
+}
+
+static const struct occ_bus_ops p8_bus_ops = {
+ .getscom = p8_i2c_getscom,
+ .putscom = p8_i2c_putscom,
+};
+
+static int p8_occ_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct occ *occ;
+ struct occ_sysfs *hwmon;
+ const u32 *sensor_hwmon_configs = p8_get_sensor_hwmon_configs();
+
+ occ = p8_occ_init(&client->dev, client, &p8_bus_ops);
+ if (IS_ERR(occ))
+ return PTR_ERR(occ);
+
+ hwmon = occ_sysfs_start(&client->dev, occ, sensor_hwmon_configs,
+ OCC_P8_I2C_NAME);
+ if (IS_ERR(hwmon))
+ return PTR_ERR(hwmon);
+
+ i2c_set_clientdata(client, occ);
+
+ return 0;
+}
+
+/* used by old-style board info. */
+static const struct i2c_device_id occ_ids[] = {
+ { OCC_P8_I2C_NAME, 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, occ_ids);
+
+/* used by device table */
+static const struct of_device_id occ_of_match[] = {
+ { .compatible = "ibm,p8-occ-i2c" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, occ_of_match);
+
+static struct i2c_driver p8_occ_driver = {
+ .class = I2C_CLASS_HWMON,
+ .driver = {
+ .name = OCC_P8_I2C_NAME,
+ .of_
[PATCH linux v9 3/5] hwmon: occ: Add I2C transport implementation for SCOM operations
From: "Edward A. James"
Add functions to send SCOM operations over I2C bus. The BMC can
communicate with the Power8 host processor over I2C, but needs to use
SCOM operations in order to access the OCC register space.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
drivers/hwmon/occ/Makefile | 2 +-
drivers/hwmon/occ/occ_scom_i2c.c | 69
drivers/hwmon/occ/occ_scom_i2c.h | 21
3 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 67b5367..9cc36e7 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o
+obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o occ_scom_i2c.o
diff --git a/drivers/hwmon/occ/occ_scom_i2c.c b/drivers/hwmon/occ/occ_scom_i2c.c
new file mode 100644
index 000..351cbc5
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.c
@@ -0,0 +1,69 @@
+/*
+ * occ_scom_i2c.c - hwmon OCC driver
+ *
+ * This file contains the functions for performing SCOM operations over I2C bus
+ * to access the OCC.
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include "occ_scom_i2c.h"
+#include "scom.h"
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ ssize_t rc;
+ __be64 buf;
+ struct i2c_client *client = bus;
+ struct i2c_msg msgs[2];
+
+ msgs[0].addr = client->addr;
+ msgs[0].flags = client->flags & I2C_M_TEN;
+ msgs[0].len = sizeof(u32);
+ msgs[0].buf = (char *)&address;
+
+ msgs[1].addr = client->addr;
+ msgs[1].flags = (client->flags & I2C_M_TEN) | I2C_M_RD;
+ msgs[1].len = sizeof(u64);
+ msgs[1].buf = (char *)&buf;
+
+ rc = i2c_transfer(client->adapter, msgs, 2);
+ if (rc < 0)
+ return rc;
+
+ *data = be64_to_cpu(buf);
+
+ return 0;
+}
+
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+ u32 buf[3];
+ ssize_t rc;
+ struct i2c_client *client = bus;
+
+ /* send raw data, user can handle endian */
+ buf[0] = address;
+ buf[1] = data1;
+ buf[2] = data0;
+
+ rc = i2c_master_send(client, (const char *)buf, sizeof(u32) * 3);
+ if (rc < 0)
+ return rc;
+ else if (rc != sizeof(u32) * 3)
+ return -EIO;
+
+ return 0;
+}
+
+MODULE_AUTHOR("Eddie James ");
+MODULE_DESCRIPTION("I2C OCC SCOM transport");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/occ/occ_scom_i2c.h b/drivers/hwmon/occ/occ_scom_i2c.h
new file mode 100644
index 000..f84647d
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.h
@@ -0,0 +1,21 @@
+/*
+ * occ_scom_i2c.h - hwmon OCC driver
+ *
+ * This file contains function protoypes for peforming SCOM operations over I2C
+ * bus to access the OCC.
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __OCC_SCOM_I2C_H__
+#define __OCC_SCOM_I2C_H__
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data);
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1);
+
+#endif /* __OCC_SCOM_I2C_H__ */
--
1.8.3.1
[tip:x86/urgent] x86/intel_rdt: Put group node in rdtgroup_kn_unlock
Commit-ID: 49ec8f5b6ae3ab60385492cad900ffc8a523c895
Gitweb: http://git.kernel.org/tip/49ec8f5b6ae3ab60385492cad900ffc8a523c895
Author: Jiri Olsa
AuthorDate: Tue, 14 Mar 2017 15:20:53 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 14 Mar 2017 21:51:58 +0100
x86/intel_rdt: Put group node in rdtgroup_kn_unlock
The rdtgroup_kn_unlock waits for the last user to release and put its
node. But it's calling kernfs_put on the node which calls the
rdtgroup_kn_unlock, which might not be the group's directory node, but
another group's file node.
This race could be easily reproduced by running 2 instances
of following script:
mount -t resctrl resctrl /sys/fs/resctrl/
pushd /sys/fs/resctrl/
mkdir krava
echo "krava" > krava/schemata
rmdir krava
popd
umount /sys/fs/resctrl
It triggers the slub debug error message with following command
line config: slub_debug=,kernfs_node_cache.
Call kernfs_put on the group's node to fix it.
Fixes: 60cf5e101fd4 ("x86/intel_rdt: Add mkdir to resctrl file system")
Signed-off-by: Jiri Olsa
Cc: Fenghua Yu
Cc: Peter Zijlstra
Cc: Peter Zijlstra
Cc: Mike Galbraith
Cc: Shaohua Li
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1489501253-20248-1-git-send-email-jo...@kernel.org
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index c05509d..9ac2a5c 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -727,7 +727,7 @@ void rdtgroup_kn_unlock(struct kernfs_node *kn)
if (atomic_dec_and_test(&rdtgrp->waitcount) &&
(rdtgrp->flags & RDT_DELETED)) {
kernfs_unbreak_active_protection(kn);
- kernfs_put(kn);
+ kernfs_put(rdtgrp->kn);
kfree(rdtgrp);
} else {
kernfs_unbreak_active_protection(kn);
[PATCH linux v9 1/5] hwmon: Add core On-Chip Controller support for POWER CPUs
From: "Edward A. James" Add core support for polling the OCC for it's sensor data and parsing that data into sensor-specific information. Signed-off-by: Edward A. James Signed-off-by: Andrew Jeffery --- Documentation/hwmon/occ| 42 + MAINTAINERS| 7 + drivers/hwmon/Kconfig | 2 + drivers/hwmon/Makefile | 1 + drivers/hwmon/occ/Kconfig | 13 ++ drivers/hwmon/occ/Makefile | 1 + drivers/hwmon/occ/occ.c| 440 + drivers/hwmon/occ/occ.h| 77 drivers/hwmon/occ/scom.h | 42 + 9 files changed, 625 insertions(+) create mode 100644 Documentation/hwmon/occ create mode 100644 drivers/hwmon/occ/Kconfig create mode 100644 drivers/hwmon/occ/Makefile create mode 100644 drivers/hwmon/occ/occ.c create mode 100644 drivers/hwmon/occ/occ.h create mode 100644 drivers/hwmon/occ/scom.h diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ new file mode 100644 index 000..d1c863b --- /dev/null +++ b/Documentation/hwmon/occ @@ -0,0 +1,42 @@ += +Kernel driver occ += + +Supported chips: + * POWER8 + * POWER9 + +Please note that the driver does not run on these processors. Instead, the +driver runs on a connected service processor, such as an AST2400. (see the +BMC - Host Communications section). + +Author: Eddie James + +Description +--- + +This driver implements support for the OCC (On-Chip Controller) on the IBM +POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The +OCC is an embedded processor that provides real time power and thermal +monitoring. + +This driver provides an interface on a BMC to poll OCC sensor data, set user +power caps, and perform some basic OCC error handling. + +Currently, all versions of the OCC support four types of sensor data: power, +temperature, frequency, and "caps," which indicate limits and thresholds used +internally on the OCC. + +BMC - Host Communications +- + +For the POWER8 application, the BMC can communicate with the P8 over I2C bus. +However, to access the OCC register space, any data transfer must use a SCOM +operation. SCOM is a procedure to initiate a data transfer, typically of 8 +bytes. SCOMs consist of writing a 32-bit command register and then +reading/writing two 32-bit data registers. This driver implements these +SCOM operations over I2C bus in order to communicate with the OCC. + +For the POWER9 application, the BMC can communicate with the P9 over FSI bus +and SBE engine. Once again, SCOM operations are required. This driver will +implement SCOM ops over FSI/SBE. This will require the FSI driver. diff --git a/MAINTAINERS b/MAINTAINERS index c776906..4e929fc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9266,6 +9266,13 @@ T: git git://linuxtv.org/media_tree.git S: Maintained F: drivers/media/i2c/ov7670.c +ON-CHIP CONTROLLER HWMON POWER8/POWER9 DRIVER +M: Eddie James +L: open...@lists.ozlabs.org +S: Maintained +F: Documentation/hwmon/occ +F: drivers/hwmon/occ/ + ONENAND FLASH DRIVER M: Kyungmin Park L: linux-...@lists.infradead.org diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 0649d53f3..6589933 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -1240,6 +1240,8 @@ config SENSORS_NSA320 This driver can also be built as a module. If so, the module will be called nsa320-hwmon. +source drivers/hwmon/occ/Kconfig + config SENSORS_PCF8591 tristate "Philips PCF8591 ADC/DAC" depends on I2C diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 5509edf..5b26067 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -170,6 +170,7 @@ obj-$(CONFIG_SENSORS_WM831X)+= wm831x-hwmon.o obj-$(CONFIG_SENSORS_WM8350) += wm8350-hwmon.o obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o +obj-$(CONFIG_SENSORS_IBM_OCC) += occ/ obj-$(CONFIG_PMBUS)+= pmbus/ ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig new file mode 100644 index 000..61be588 --- /dev/null +++ b/drivers/hwmon/occ/Kconfig @@ -0,0 +1,13 @@ +# +# On Chip Controller configuration +# + +menuconfig SENSORS_IBM_OCC + bool "IBM On-Chip Controller" + help + If you say yes here you get support to monitor IBM Power CPU + sensors via the On-Chip Controller (OCC), from a service + processor. + + Generally this is used by management controllers such as a BMC + on an OpenPower system. diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile new file mode 100644 index 000..3ed79a5 --- /dev/null +++ b/drivers/hwmon/occ/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o diff --git a/drivers/hwmon/occ/occ.c b/drivers/hwmon/occ/occ.c new file mode 100644 index 000..afc21f8 --- /dev/null +++ b/drivers/hwmon/occ/o
[GIT PULL] libata changes for v4.11-rc2
Hello,
Three libata fixes.
* Fix for a circular reference bug in sysfs code which prevented
pata_legacy devices from being released after probe failure, which
in turn prevented devres from releasing the associated resources.
* Drop spurious WARN in the command issue path which can be triggered
by a legitimate passthrough command.
* A ahci_qoriq specific fix.
Thanks.
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.11-fixes
for you to fetch changes up to 6022c5cadf1a43ca30f431f128daa6163909ad60:
ahci: qoriq: correct the sata ecc setting error (2017-03-09 11:55:23 -0500)
Gwendal Grignou (1):
libata: transport: Remove circular dependency at free time
Tejun Heo (1):
libata: drop WARN from protocol error in ata_sff_qc_issue()
Yuantian Tang (1):
ahci: qoriq: correct the sata ecc setting error
drivers/ata/ahci_qoriq.c | 6 --
drivers/ata/libata-sff.c | 1 -
drivers/ata/libata-transport.c | 9 +++--
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 85d8332..4c96f3a 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -177,7 +177,8 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
case AHCI_LS1043A:
if (!qpriv->ecc_addr)
return -EINVAL;
- writel(ECC_DIS_ARMV8_CH2, qpriv->ecc_addr);
+ writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2,
+ qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
if (qpriv->is_dmacoherent)
@@ -194,7 +195,8 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
case AHCI_LS1046A:
if (!qpriv->ecc_addr)
return -EINVAL;
- writel(ECC_DIS_ARMV8_CH2, qpriv->ecc_addr);
+ writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2,
+ qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
if (qpriv->is_dmacoherent)
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 2bd92dc..274d6d7 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1482,7 +1482,6 @@ unsigned int ata_sff_qc_issue(struct ata_queued_cmd *qc)
break;
default:
- WARN_ON_ONCE(1);
return AC_ERR_SYSTEM;
}
diff --git a/drivers/ata/libata-transport.c b/drivers/ata/libata-transport.c
index 4669823..19e6e53 100644
--- a/drivers/ata/libata-transport.c
+++ b/drivers/ata/libata-transport.c
@@ -224,7 +224,6 @@ static DECLARE_TRANSPORT_CLASS(ata_port_class,
static void ata_tport_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -284,7 +283,7 @@ int ata_tport_add(struct device *parent,
device_initialize(dev);
dev->type = &ata_port_type;
- dev->parent = get_device(parent);
+ dev->parent = parent;
dev->release = ata_tport_release;
dev_set_name(dev, "ata%d", ap->print_id);
transport_setup_device(dev);
@@ -348,7 +347,6 @@ static DECLARE_TRANSPORT_CLASS(ata_link_class,
static void ata_tlink_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -410,7 +408,7 @@ int ata_tlink_add(struct ata_link *link)
int error;
device_initialize(dev);
- dev->parent = get_device(&ap->tdev);
+ dev->parent = &ap->tdev;
dev->release = ata_tlink_release;
if (ata_is_host_link(link))
dev_set_name(dev, "link%d", ap->print_id);
@@ -589,7 +587,6 @@ static DECLARE_TRANSPORT_CLASS(ata_dev_class,
static void ata_tdev_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -662,7 +659,7 @@ static int ata_tdev_add(struct ata_device *ata_dev)
int error;
device_initialize(dev);
- dev->parent = get_device(&link->tdev);
+ dev->parent = &link->tdev;
dev->release = ata_tdev_release;
if (ata_is_host_link(link))
dev_set_name(dev, "dev%d.%d", ap->print_id,ata_dev->devno);
--
tejun
Re: [PATCH 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings
Hi Chris,
On Fri, Mar 03, 2017 at 09:01:48AM +0800, Chris Zhong wrote:
> The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and
> connected to DSI using four lanes.
>
> Signed-off-by: Chris Zhong
> ---
>
> .../bindings/display/panel/innolux,p079zca.txt | 22
> ++
> 1 file changed, 22 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> new file mode 100644
> index 000..c40c8e4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> @@ -0,0 +1,22 @@
> +Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "innolux,p079zca"
> +- power-supply: phandle of the regulator that provides the supply voltage
> +- enable-gpios: panel enable gpio
> +
> +Optional properties:
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> + &mipi_dsi {
> + panel {
> + compatible = "innolux,p079zca";
> + reg = <0>;
Where's the documentation for this property?
Brian
> + power-supply = <...>;
> + backlight = <&backlight>;
> + enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> + };
> + };
Re: [PATCH] mtd: nand: use .read_oob() instead of .cmdfunc() for bad block check
On Wed, 15 Mar 2017 02:45:48 +0900
Masahiro Yamada wrote:
> The nand_default_block_markbad() is the default implementation of
> chip->block_markbad(). This is called for marking a block as bad.
> It invokes nand_do_write_oob(), then calls a higher level accessor
> ecc->write_oob().
>
> On the other hand, when reading BBM from the OOB, chip->block_bad()
> is called, and nand_block_bad() is the default implementation. This
> function calls a lower level chip->cmdfunc(). If a driver wants to
> re-use nand_block_bad(), it is required to support NAND_CMD_READOOB
> in its cmdfunc().
This is part of the basic/mandatory operations that should be supported
by all drivers.
> This is strange. If the controller supports
> optimized read operation and the driver has its own ecc->read_oob(),
> it should be able to use it.
I agree with this one. I guess the idea behind this default
implementation was to avoid reading the whole OOB area, or maybe this
function was implemented before we had ECC support. Anyway, the
overhead should be negligible with your approach.
> Besides, NAND_CMD_READOOB (0x50) is
> not a real command for large page devices. So, recent drivers may
> not be happy to handle this command.
Well, that's the whole problem with the ->cmdfunc() hook, even if it's
passed raw NAND command identifiers, these are actually encoding NAND
operations, and not necessarily the exact command that should be sent to
the NAND.
See what's done in nand_command_lp(), and how some commands are
actually generating a sequence of 2 commands [1], or how
NAND_CMD_READOOB is transformed into NAND_CMD_READ0 [2].
My plan was to add a ->exec_op() hook that would be passed the whole
operation description (cmds+addrs+data info) and progressively get rid
of ->cmdfunc(), but I never had time to finish the implementation[3].
>
> Signed-off-by: Masahiro Yamada
> ---
>
> At first, I tried to call nand_do_read_oob() from nand_block_bad()
> in order to make to make things symmetry, but it did not work.
> chip->select_chip() is handled outside of nand_block_bad(), so
> nand_do_read_oob() can not be used there.
>
>
> drivers/mtd/nand/nand_base.c | 38 +-
> 1 file changed, 17 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index a3c0f47..78c5cd6 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -354,9 +354,9 @@ static void nand_read_buf16(struct mtd_info *mtd, uint8_t
> *buf, int len)
> */
> static int nand_block_bad(struct mtd_info *mtd, loff_t ofs)
> {
> - int page, res = 0, i = 0;
> + int page, res = 0, ret = 0, i = 0;
> struct nand_chip *chip = mtd_to_nand(mtd);
> - u16 bad;
> + u8 bad;
>
> if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
> ofs += mtd->erasesize - mtd->writesize;
> @@ -364,30 +364,26 @@ static int nand_block_bad(struct mtd_info *mtd, loff_t
> ofs)
> page = (int)(ofs >> chip->page_shift) & chip->pagemask;
>
> do {
> - if (chip->options & NAND_BUSWIDTH_16) {
> - chip->cmdfunc(mtd, NAND_CMD_READOOB,
> - chip->badblockpos & 0xFE, page);
> - bad = cpu_to_le16(chip->read_word(mtd));
> - if (chip->badblockpos & 0x1)
> - bad >>= 8;
> + res = chip->ecc.read_oob(mtd, chip, page);
> + if (!res) {
> + bad = chip->oob_poi[chip->badblockpos];
Hm, even if the current code is only testing one byte, I wonder
if we shouldn't test the 2 bytes here when we're dealing with 16bits
NANDs.
> +
> + if (likely(chip->badblockbits == 8))
> + res = bad != 0xFF;
> else
> - bad &= 0xFF;
> - } else {
> - chip->cmdfunc(mtd, NAND_CMD_READOOB, chip->badblockpos,
> - page);
> - bad = chip->read_byte(mtd);
> + res = hweight8(bad) < chip->badblockbits;
> + if (res)
> + return res;
> }
>
> - if (likely(chip->badblockbits == 8))
> - res = bad != 0xFF;
> - else
> - res = hweight8(bad) < chip->badblockbits;
> - ofs += mtd->writesize;
> - page = (int)(ofs >> chip->page_shift) & chip->pagemask;
> + if (!ret)
> + ret = res;
Hm, I'm not sure I understand what you're doing here. If res is != 0,
then an error occurred when reading the OOB area and you should
probably return the error code directly instead of trying to read the
OOB from next page. On the other hand, if res is 0, then ret will
always be 0, so I don't think this extra ret variable is needed.
> +
> + page++;
>
Re: [PATCH v5 2/7] perf tool: Add option macro OPT_CALLBACK_ARG
Em Tue, Mar 14, 2017 at 08:36:53PM +0530, Ravi Bangoria escreveu:
> Add an option macro that is the same as OPT_CALLBACK_OPTARG except
> that the argument is not optional.
Not 'perf tool:', adjusted to 'tools lib subcmd:' as this is not perf
specific at all, tools/lib/subcmd/ is by other tools, such as objtool.
- Arnaldo
> Signed-off-by: Ravi Bangoria
> ---
> tools/lib/subcmd/parse-options.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/lib/subcmd/parse-options.h
> b/tools/lib/subcmd/parse-options.h
> index f054ca1..79472e0 100644
> --- a/tools/lib/subcmd/parse-options.h
> +++ b/tools/lib/subcmd/parse-options.h
> @@ -160,6 +160,10 @@ struct option {
> { .type = OPTION_CALLBACK, .short_name = (s), .long_name = (l), \
> .value = (v), .argh = (a), .help = (h), .callback = (f), \
> .flags = PARSE_OPT_OPTARG, .data = (d) }
> +#define OPT_CALLBACK_ARG(s, l, v, d, a, h, f) \
> + { .type = OPTION_CALLBACK, .short_name = (s), .long_name = (l), \
> + .value = (v), .argh = (a), .help = (h), .callback = (f), \
> + .data = (d) }
>
> /* parse_options() will filter out the processed options and leave the
> * non-option argments in argv[].
> --
> 2.9.3
[GIT PULL] cgroup changes for v4.11-rc2
Hello, Linus.
Three cgroup fixes. Nothing critical.
* The pids controller could trigger suspicious RCU warning spuriously.
Fixed.
* In the debug controller, %p -> %pK to protect kernel pointer from
getting exposed.
* Documentation formatting fix.
Thanks.
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-4.11-fixes
for you to fetch changes up to b6a6759daf55dade2b65089957832759d502acfb:
cgroups: censor kernel pointer in debug files (2017-03-06 15:16:03 -0500)
Kees Cook (1):
cgroups: censor kernel pointer in debug files
Tejun Heo (1):
cgroup/pids: remove spurious suspicious RCU usage warning
Tobias Klauser (1):
cgroup: Fix indenting in PID controller documentation
Documentation/cgroup-v2.txt | 11 ++-
kernel/cgroup/cgroup-v1.c | 2 +-
kernel/cgroup/pids.c| 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index 3b8449f..49d7c99 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -1142,16 +1142,17 @@ used by the kernel.
pids.max
- A read-write single value file which exists on non-root cgroups. The
- default is "max".
+ A read-write single value file which exists on non-root
+ cgroups. The default is "max".
- Hard limit of number of processes.
+ Hard limit of number of processes.
pids.current
- A read-only single value file which exists on all cgroups.
+ A read-only single value file which exists on all cgroups.
- The number of processes currently in the cgroup and its descendants.
+ The number of processes currently in the cgroup and its
+ descendants.
Organisational operations are not blocked by cgroup policies, so it is
possible to have pids.current > pids.max. This can be done by either
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 56eba9c..1dc22f6 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -1329,7 +1329,7 @@ static int cgroup_css_links_read(struct seq_file *seq,
void *v)
struct task_struct *task;
int count = 0;
- seq_printf(seq, "css_set %p\n", cset);
+ seq_printf(seq, "css_set %pK\n", cset);
list_for_each_entry(task, &cset->tasks, cg_list) {
if (count++ > MAX_TASKS_SHOWN_PER_CSS)
diff --git a/kernel/cgroup/pids.c b/kernel/cgroup/pids.c
index e756dae..2237201 100644
--- a/kernel/cgroup/pids.c
+++ b/kernel/cgroup/pids.c
@@ -229,7 +229,7 @@ static int pids_can_fork(struct task_struct *task)
/* Only log the first time events_limit is incremented. */
if (atomic64_inc_return(&pids->events_limit) == 1) {
pr_info("cgroup: fork rejected by pids controller in ");
- pr_cont_cgroup_path(task_cgroup(current, pids_cgrp_id));
+ pr_cont_cgroup_path(css->cgroup);
pr_cont("\n");
}
cgroup_file_notify(&pids->events_file);
--
tejun
Re: [PATCH] staging: vc04_services: Remove unused functions
> Jean-Baptiste Abbadie hat am 14. März 2017 um 20:14 > geschrieben: > > > These four functions are not used and report errors with sparse. > > Signed-off-by: Jean-Baptiste Abbadie Acked-by: Stefan Wahren
Re: [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit
On Tue 2017-03-14 10:05:08, Thomas Garnier wrote: > This patch makes the GDT remapped pages read-only to prevent corruption. > This change is done only on 64-bit. > > The native_load_tr_desc function was adapted to correctly handle a > read-only GDT. The LTR instruction always writes to the GDT TSS entry. > This generates a page fault if the GDT is read-only. This change checks > if the current GDT is a remap and swap GDTs as needed. This function was > tested by booting multiple machines and checking hibernation works > properly. > > KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the > per-cpu variable was removed for functions to fetch the original GDT. > Instead of reloading the previous GDT, VMX will reload the fixmap GDT as > expected. For testing, VMs were started and restored on multiple > configurations. > > Signed-off-by: Thomas Garnier Can we get the same change for 32-bit, too? Growing differences between 32 and 64 bit are a bit of a problem... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH] drm/vmwgfx: avoid gcc-7 parentheses warning
gcc-7 warns about slightly suspicious code in vmw_cmd_invalid:
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid':
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle
operand in ?: will always be 'true', suggest explicit middle operand
[-Werror=parentheses]
The problem is that it is mixing boolean and integer values here.
I assume that the code actually works correctly, so making it use
a literal '1' instead of the implied 'true' makes it more readable
and avoids the warning.
The code has been in this file since the start, but it could
make sense to backport this patch to stable to make it build cleanly
with gcc-7.
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Reviewed-by: Sinclair Yeh
Signed-off-by: Arnd Bergmann
---
Originally submitted on Nov 16, but for some reason it never appeared
upstream. The patch is still needed as of v4.11-rc2
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index c7b53d987f06..3f343e55972a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -519,7 +519,7 @@ static int vmw_cmd_invalid(struct vmw_private *dev_priv,
struct vmw_sw_context *sw_context,
SVGA3dCmdHeader *header)
{
- return capable(CAP_SYS_ADMIN) ? : -EINVAL;
+ return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
}
static int vmw_cmd_ok(struct vmw_private *dev_priv,
--
2.9.0
[PATCH] firmware: ti_sci: fix strncat length check
gcc-7 notices that the length we pass to strncat is wrong:
drivers/firmware/ti_sci.c: In function 'ti_sci_probe':
drivers/firmware/ti_sci.c:204:32: error: specified bound 50 equals the size of
the destination [-Werror=stringop-overflow=]
Instead of the total length, we must pass the length of the
remaining space here.
Fixes: aa276781a64a ("firmware: Add basic support for TI System Control
Interface (TI-SCI) protocol")
Acked-by: Nishanth Menon
Signed-off-by: Arnd Bergmann
---
Originally submitted on Jan 11, patch is still needed on Linux-4.11-rc2.
---
drivers/firmware/ti_sci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 874ff32db366..00cfed3c3e1a 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -202,7 +202,8 @@ static int ti_sci_debugfs_create(struct platform_device
*pdev,
info->debug_buffer[info->debug_region_size] = 0;
info->d = debugfs_create_file(strncat(debug_name, dev_name(dev),
- sizeof(debug_name)),
+ sizeof(debug_name) -
+ sizeof("ti_sci_debug@")),
0444, NULL, info, &ti_sci_debug_fops);
if (IS_ERR(info->d))
return PTR_ERR(info->d);
--
2.9.0
Re: [PATCH] firmware: ti_sci: fix strncat length check
On 3/14/17 2:11 PM, Arnd Bergmann wrote:
gcc-7 notices that the length we pass to strncat is wrong:
drivers/firmware/ti_sci.c: In function 'ti_sci_probe':
drivers/firmware/ti_sci.c:204:32: error: specified bound 50 equals the size of
the destination [-Werror=stringop-overflow=]
Instead of the total length, we must pass the length of the
remaining space here.
Fixes: aa276781a64a ("firmware: Add basic support for TI System Control Interface
(TI-SCI) protocol")
Acked-by: Nishanth Menon
Signed-off-by: Arnd Bergmann
---
Originally submitted on Jan 11, patch is still needed on Linux-4.11-rc2.
Looks fine to me Arnd. Will you be applying it to SOC driver branch ?
Acked-by: Santosh Shilimkar
Re: [PATCH v4 05/11] mm: thp: enable thp migration in generic path
Hi Naoya,
[auto build test WARNING on mmotm/master]
[also build test WARNING on next-20170310]
[cannot apply to v4.11-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Zi-Yan/mm-page-migration-enhancement-for-thp/20170315-042736
base: git://git.cmpxchg.org/linux-mmotm.git master
config: m68k-sun3_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All warnings (new ones prefixed by >>):
In file included from fs/proc/task_mmu.c:15:0:
include/linux/swapops.h: In function 'remove_migration_pmd':
include/linux/swapops.h:209:2: warning: 'return' with a value, in function
returning void
return 0;
^
include/linux/swapops.h: In function 'swp_entry_to_pmd':
>> include/linux/swapops.h:223:2: warning: missing braces around initializer
>> [-Wmissing-braces]
return (pmd_t){ 0 };
^
include/linux/swapops.h:223:2: warning: (near initialization for
'(anonymous).pmd') [-Wmissing-braces]
vim +223 include/linux/swapops.h
203 }
204
205 static inline void remove_migration_pmd(struct page_vma_mapped_walk
*pvmw,
206 struct page *new)
207 {
208 BUILD_BUG();
> 209 return 0;
210 }
211
212 static inline void pmd_migration_entry_wait(struct mm_struct *m, pmd_t
*p) { }
213
214 static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
215 {
216 BUILD_BUG();
217 return swp_entry(0, 0);
218 }
219
220 static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
221 {
222 BUILD_BUG();
> 223 return (pmd_t){ 0 };
224 }
225
226 static inline int is_pmd_migration_entry(pmd_t pmd)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[RESEND PATCH] drbd: avoid clang warning about unmatched switch statement
The drbd code causes warnings that we cannot easily disable when building with
clang:
In file included from drivers/block/drbd/drbd_debugfs.c:10:
In file included from drivers/block/drbd/drbd_int.h:48:
In file included from include/linux/drbd_genl_api.h:53:
In file included from include/linux/genl_magic_struct.h:237:
include/linux/drbd_genl.h:300:1: warning: no case matching constant switch
condition '0'
There is nothing wrong with the code, and adding 'default:' labels
in the right place is enough to let clang shut up about the warning.
Fixes: ec2c35ac1ea2 ("drbd: prepare the transition from connector to genetlink")
Signed-off-by: Arnd Bergmann
Acked-by: Lars Ellenberg
---
Originally submitted on Feb 1, but not yet merged into v4.11-rc2
---
include/linux/genl_magic_struct.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/genl_magic_struct.h
b/include/linux/genl_magic_struct.h
index 6270a56e5edc..c6fbafb834f1 100644
--- a/include/linux/genl_magic_struct.h
+++ b/include/linux/genl_magic_struct.h
@@ -190,6 +190,7 @@ static inline void ct_assert_unique_operations(void)
{
switch (0) {
#include GENL_MAGIC_INCLUDE_FILE
+ default:
;
}
}
@@ -208,6 +209,7 @@ static inline void
ct_assert_unique_top_level_attributes(void)
{
switch (0) {
#include GENL_MAGIC_INCLUDE_FILE
+ default:
;
}
}
@@ -218,6 +220,7 @@ static inline void ct_assert_unique_ ## s_name ##
_attributes(void) \
{ \
switch (0) {\
s_fields\
+ default:\
; \
} \
}
--
2.9.0
Re: [PATCH v5 4/6] dt-bindings: gpio: Add binding documentation for gpio-thunderx
On Tue, Mar 14, 2017 at 5:45 PM, David Daney wrote: > On 03/14/2017 07:53 AM, Linus Walleij wrote: >> >> On Wed, Mar 1, 2017 at 2:48 AM, David Daney >> wrote: >> >>> Signed-off-by: David Daney >>> Acked-by: Rob Herring >> >> >> This patch applied to the GPIO tree, really simplistic so why not >> merge it. > > > I think the idea is that with Rob's Acked-by, it could be merged via the > GPIO tree when and if the other patches in the set are merged. Since I > don't maintain any trees pulled by Linus Torvalds, I am at the mercy of the > various maintainers. I agree that the code changes need to go in together. But DT bindings are sort of decoupled from the kernel i general (they are theoretically also used by other OSes such as *BSD) so they can be merged in an orthogonal manner once they are considered finished. No biggie for me though, if you prefer, I can pull it out. Yours, Linus Walleij
[PATCH v2 4/5] MIPS: BPF: Quit clobbering callee saved registers in JIT code.
If bpf_needs_clear_a() returns true, only actually clear it if it is ever used. If it is not used, we don't save and restore it, so the clearing has the nasty side effect of clobbering caller state. Also, don't emit stack pointer adjustment instructions if the adjustment amount is zero. Signed-off-by: David Daney --- arch/mips/net/bpf_jit.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/arch/mips/net/bpf_jit.c b/arch/mips/net/bpf_jit.c index a68cd36..44b9250 100644 --- a/arch/mips/net/bpf_jit.c +++ b/arch/mips/net/bpf_jit.c @@ -532,7 +532,8 @@ static void save_bpf_jit_regs(struct jit_ctx *ctx, unsigned offset) u32 sflags, tmp_flags; /* Adjust the stack pointer */ - emit_stack_offset(-align_sp(offset), ctx); + if (offset) + emit_stack_offset(-align_sp(offset), ctx); tmp_flags = sflags = ctx->flags >> SEEN_SREG_SFT; /* sflags is essentially a bitmap */ @@ -584,7 +585,8 @@ static void restore_bpf_jit_regs(struct jit_ctx *ctx, emit_load_stack_reg(r_ra, r_sp, real_off, ctx); /* Restore the sp and discard the scrach memory */ - emit_stack_offset(align_sp(offset), ctx); + if (offset) + emit_stack_offset(align_sp(offset), ctx); } static unsigned int get_stack_depth(struct jit_ctx *ctx) @@ -631,8 +633,14 @@ static void build_prologue(struct jit_ctx *ctx) if (ctx->flags & SEEN_X) emit_jit_reg_move(r_X, r_zero, ctx); - /* Do not leak kernel data to userspace */ - if (bpf_needs_clear_a(&ctx->skf->insns[0])) + /* +* Do not leak kernel data to userspace, we only need to clear +* r_A if it is ever used. In fact if it is never used, we +* will not save/restore it, so clearing it in this case would +* corrupt the state of the caller. +*/ + if (bpf_needs_clear_a(&ctx->skf->insns[0]) && + (ctx->flags & SEEN_A)) emit_jit_reg_move(r_A, r_zero, ctx); } -- 2.9.3
[PATCH v2 5/5] MIPS: BPF: Fix multiple problems in JIT skb access helpers.
o Socket data is unsigned, so use unsigned accessors instructions. o Fix path result pointer generation arithmetic. o Fix half-word byte swapping code for unsigned semantics. Signed-off-by: David Daney --- arch/mips/net/bpf_jit_asm.S | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/arch/mips/net/bpf_jit_asm.S b/arch/mips/net/bpf_jit_asm.S index 5d2e0c8..88a2075 100644 --- a/arch/mips/net/bpf_jit_asm.S +++ b/arch/mips/net/bpf_jit_asm.S @@ -90,18 +90,14 @@ FEXPORT(sk_load_half_positive) is_offset_in_header(2, half) /* Offset within header boundaries */ PTR_ADDU t1, $r_skb_data, offset - .setreorder - lh $r_A, 0(t1) - .setnoreorder + lhu $r_A, 0(t1) #ifdef CONFIG_CPU_LITTLE_ENDIAN # if defined(__mips_isa_rev) && (__mips_isa_rev >= 2) - wsbht0, $r_A - seh $r_A, t0 + wsbh$r_A, $r_A # else - sll t0, $r_A, 24 - andit1, $r_A, 0xff00 - sra t0, t0, 16 - srl t1, t1, 8 + sll t0, $r_A, 8 + srl t1, $r_A, 8 + andit0, t0, 0xff00 or $r_A, t0, t1 # endif #endif @@ -115,7 +111,7 @@ FEXPORT(sk_load_byte_positive) is_offset_in_header(1, byte) /* Offset within header boundaries */ PTR_ADDU t1, $r_skb_data, offset - lb $r_A, 0(t1) + lbu $r_A, 0(t1) jr $r_ra move $r_ret, zero END(sk_load_byte) @@ -139,6 +135,11 @@ FEXPORT(sk_load_byte_positive) * (void *to) is returned in r_s0 * */ +#ifdef CONFIG_CPU_LITTLE_ENDIAN +#define DS_OFFSET(SIZE) (4 * SZREG) +#else +#define DS_OFFSET(SIZE) ((4 * SZREG) + (4 - SIZE)) +#endif #define bpf_slow_path_common(SIZE) \ /* Quick check. Are we within reasonable boundaries? */ \ LONG_ADDIU $r_s1, $r_skb_len, -SIZE; \ @@ -150,7 +151,7 @@ FEXPORT(sk_load_byte_positive) PTR_LA t0, skb_copy_bits; \ PTR_S $r_ra, (5 * SZREG)($r_sp); \ /* Assign low slot to a2 */ \ - movea2, $r_sp; \ + PTR_ADDIU a2, $r_sp, DS_OFFSET(SIZE); \ jalrt0; \ /* Reset our destination slot (DS but it's ok) */ \ INT_S zero, (4 * SZREG)($r_sp); \ -- 2.9.3
[PATCH v2 3/5] MIPS: BPF: Use unsigned access for unsigned SKB fields.
The SKB vlan_tci and queue_mapping fields are unsigned, don't sign
extend these in the BPF JIT. In the vlan_tci case, the value gets
masked so the change is not needed for correctness, but do it anyway
for agreement with the types defined in struct sk_buff.
Signed-off-by: David Daney
---
arch/mips/net/bpf_jit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/net/bpf_jit.c b/arch/mips/net/bpf_jit.c
index 880e329..a68cd36 100644
--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -1156,7 +1156,7 @@ static int build_body(struct jit_ctx *ctx)
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff,
vlan_tci) != 2);
off = offsetof(struct sk_buff, vlan_tci);
- emit_half_load(r_s0, r_skb, off, ctx);
+ emit_half_load_unsigned(r_s0, r_skb, off, ctx);
if (code == (BPF_ANC | SKF_AD_VLAN_TAG)) {
emit_andi(r_A, r_s0, (u16)~VLAN_TAG_PRESENT,
ctx);
} else {
@@ -1183,7 +1183,7 @@ static int build_body(struct jit_ctx *ctx)
BUILD_BUG_ON(offsetof(struct sk_buff,
queue_mapping) > 0xff);
off = offsetof(struct sk_buff, queue_mapping);
- emit_half_load(r_A, r_skb, off, ctx);
+ emit_half_load_unsigned(r_A, r_skb, off, ctx);
break;
default:
pr_debug("%s: Unhandled opcode: 0x%02x\n", __FILE__,
--
2.9.3
[PATCH v2 1/5] MIPS: uasm: Add support for LHU.
The follow-on BPF JIT patches use the LHU instruction, so add it.
Signed-off-by: David Daney
---
arch/mips/include/asm/uasm.h | 1 +
arch/mips/mm/uasm-mips.c | 1 +
arch/mips/mm/uasm.c | 3 ++-
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/uasm.h b/arch/mips/include/asm/uasm.h
index f7929f6..d7e84f1 100644
--- a/arch/mips/include/asm/uasm.h
+++ b/arch/mips/include/asm/uasm.h
@@ -135,6 +135,7 @@ Ip_u2s3u1(_lb);
Ip_u2s3u1(_ld);
Ip_u3u1u2(_ldx);
Ip_u2s3u1(_lh);
+Ip_u2s3u1(_lhu);
Ip_u2s3u1(_ll);
Ip_u2s3u1(_lld);
Ip_u1s2(_lui);
diff --git a/arch/mips/mm/uasm-mips.c b/arch/mips/mm/uasm-mips.c
index 763d3f1..2277499 100644
--- a/arch/mips/mm/uasm-mips.c
+++ b/arch/mips/mm/uasm-mips.c
@@ -103,6 +103,7 @@ static struct insn insn_table[] = {
{ insn_ld, M(ld_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
{ insn_ldx, M(spec3_op, 0, 0, 0, ldx_op, lx_op), RS | RT | RD },
{ insn_lh, M(lh_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_lhu, M(lhu_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
#ifndef CONFIG_CPU_MIPSR6
{ insn_lld, M(lld_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
{ insn_ll, M(ll_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
diff --git a/arch/mips/mm/uasm.c b/arch/mips/mm/uasm.c
index a829704..7f400c8 100644
--- a/arch/mips/mm/uasm.c
+++ b/arch/mips/mm/uasm.c
@@ -61,7 +61,7 @@ enum opcode {
insn_sllv, insn_slt, insn_sltiu, insn_sltu, insn_sra, insn_srl,
insn_srlv, insn_subu, insn_sw, insn_sync, insn_syscall, insn_tlbp,
insn_tlbr, insn_tlbwi, insn_tlbwr, insn_wait, insn_wsbh, insn_xor,
- insn_xori, insn_yield, insn_lddir, insn_ldpte,
+ insn_xori, insn_yield, insn_lddir, insn_ldpte, insn_lhu,
};
struct insn {
@@ -297,6 +297,7 @@ I_u1(_jr)
I_u2s3u1(_lb)
I_u2s3u1(_ld)
I_u2s3u1(_lh)
+I_u2s3u1(_lhu)
I_u2s3u1(_ll)
I_u2s3u1(_lld)
I_u1s2(_lui)
--
2.9.3
[PATCH v2 0/5] MIPS: BPF: JIT fixes and improvements.
Changes from v1: - Use unsigned access for SKF_AD_HATYPE - Added three more patches for other problems found. Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module identified some failures and unimplemented features. With this patch set we get: test_bpf: Summary: 305 PASSED, 0 FAILED, [85/297 JIT'ed] Both big and little endian tested. We still lack eBPF support, but this is better than nothing. David Daney (5): MIPS: uasm: Add support for LHU. MIPS: BPF: Add JIT support for SKF_AD_HATYPE. MIPS: BPF: Use unsigned access for unsigned SKB fields. MIPS: BPF: Quit clobbering callee saved registers in JIT code. MIPS: BPF: Fix multiple problems in JIT skb access helpers. arch/mips/include/asm/uasm.h | 1 + arch/mips/mm/uasm-mips.c | 1 + arch/mips/mm/uasm.c | 3 ++- arch/mips/net/bpf_jit.c | 41 +++-- arch/mips/net/bpf_jit_asm.S | 23 --- 5 files changed, 47 insertions(+), 22 deletions(-) -- 2.9.3
[PATCH] net: sun: sungem: rix a possible null dereference
The function gem_begin_auto_negotiation dereference
the pointer ep before testing if it's null. This
patch add a check on ep before dereferencing it.
This issue was added by the patch 92552fdd557:
"net: sun: sungem: use new api ethtool_{get|set}_link_ksettings".
Reported-by: Dan Carpenter
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/sun/sungem.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sun/sungem.c
b/drivers/net/ethernet/sun/sungem.c
index dbfca04..fa607d0 100644
--- a/drivers/net/ethernet/sun/sungem.c
+++ b/drivers/net/ethernet/sun/sungem.c
@@ -1259,8 +1259,9 @@ static void gem_begin_auto_negotiation(struct gem *gp,
int duplex;
u32 advertising;
- ethtool_convert_link_mode_to_legacy_u32(&advertising,
- ep->link_modes.advertising);
+ if (ep)
+ ethtool_convert_link_mode_to_legacy_u32(
+ &advertising, ep->link_modes.advertising);
if (gp->phy_type != phy_mii_mdio0 &&
gp->phy_type != phy_mii_mdio1)
--
1.7.4.4
Re: [PATCH v3 4/7] xen/9pfs: connect to the backend
Hi Juergen,
thank you for the review!
On Tue, 14 Mar 2017, Juergen Gross wrote:
> On 14/03/17 00:50, Stefano Stabellini wrote:
> > Implement functions to handle the xenbus handshake. Upon connection,
> > allocate the rings according to the protocol specification.
> >
> > Initialize a work_struct and a wait_queue. The work_struct will be used
> > to schedule work upon receiving an event channel notification from the
> > backend. The wait_queue will be used to wait when the ring is full and
> > we need to send a new request.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen
> > CC: Ron Minnich
> > CC: Latchesar Ionkov
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> > net/9p/trans_xen.c | 240
> > +
> > 1 file changed, 240 insertions(+)
> >
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > index f072876..974bac3 100644
> > --- a/net/9p/trans_xen.c
> > +++ b/net/9p/trans_xen.c
> > @@ -41,6 +41,35 @@
> > #include
> > #include
> >
> > +#define XEN_9PFS_NUM_RINGS 2
> > +
> > +/* One per ring, more than one per 9pfs share */
> > +struct xen_9pfs_dataring {
> > + struct xen_9pfs_front_priv *priv;
> > +
> > + struct xen_9pfs_data_intf *intf;
> > + grant_ref_t ref;
> > + int evtchn;
> > + int irq;
> > + spinlock_t lock;
> > +
> > + struct xen_9pfs_data data;
> > + wait_queue_head_t wq;
> > + struct work_struct work;
> > +};
> > +
> > +/* One per 9pfs share */
> > +struct xen_9pfs_front_priv {
> > + struct list_head list;
> > + struct xenbus_device *dev;
> > + char *tag;
> > + struct p9_client *client;
> > +
> > + int num_rings;
> > + struct xen_9pfs_dataring *rings;
> > +};
> > +static LIST_HEAD(xen_9pfs_devs);
> > +
> > static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
> > {
> > return 0;
> > @@ -60,6 +89,21 @@ static int p9_xen_request(struct p9_client *client,
> > struct p9_req_t *p9_req)
> > return 0;
> > }
> >
> > +static void p9_xen_response(struct work_struct *work)
> > +{
> > +}
> > +
> > +static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
> > +{
> > + struct xen_9pfs_dataring *ring = r;
> > + BUG_ON(!ring || !ring->priv->client);
> > +
> > + wake_up_interruptible(&ring->wq);
> > + schedule_work(&ring->work);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > static struct p9_trans_module p9_xen_trans = {
> > .name = "xen",
> > .maxsize = (1 << (XEN_9PFS_RING_ORDER + XEN_PAGE_SHIFT)),
> > @@ -76,25 +120,221 @@ static int p9_xen_request(struct p9_client *client,
> > struct p9_req_t *p9_req)
> > { "" }
> > };
> >
> > +static int xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
>
> Return type void? You are always returning 0.
Good point
> > +{
> > + int i, j;
> > +
> > + list_del(&priv->list);
> > +
> > + for (i = 0; i < priv->num_rings; i++) {
> > + if (priv->rings[i].intf == NULL)
> > + break;
> > + if (priv->rings[i].irq > 0)
> > + unbind_from_irqhandler(priv->rings[i].irq, priv->dev);
> > + if (priv->rings[i].data.in != NULL) {
> > + for (j = 0; j < (1 << XEN_9PFS_RING_ORDER); j++)
> > +
> > gnttab_end_foreign_access(priv->rings[i].intf->ref[j], 0, 0);
> > + free_pages((unsigned long)priv->rings[i].data.in,
> > + XEN_9PFS_RING_ORDER - (PAGE_SHIFT -
> > XEN_PAGE_SHIFT));
> > + }
> > + gnttab_end_foreign_access(priv->rings[i].ref, 0, 0);
> > + free_page((unsigned long)priv->rings[i].intf);
> > + }
> > + kfree(priv->rings);
> > + kfree(priv);
> > +
> > + return 0;
> > +}
> > +
> > static int xen_9pfs_front_remove(struct xenbus_device *dev)
> > {
> > + int ret;
> > + struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev);
> > +
> > + dev_set_drvdata(&dev->dev, NULL);
> > + ret = xen_9pfs_front_free(priv);
> > + return ret;
> > +}
> > +
> > +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
> > + struct xen_9pfs_dataring *ring)
> > +{
> > + int i = 0;
> > + int ret = -ENOMEM;
> > + void *bytes = NULL;
> > +
> > + init_waitqueue_head(&ring->wq);
> > + spin_lock_init(&ring->lock);
> > + INIT_WORK(&ring->work, p9_xen_response);
> > +
> > + ring->intf = (struct xen_9pfs_data_intf *) get_zeroed_page(GFP_KERNEL |
> > __GFP_ZERO);
>
> I don't think you need __GFP_ZERO here.
You are right
> > + if (!ring->intf)
> > + return ret;
> > + ret = ring->ref = gnttab_grant_foreign_access(dev->otherend_id,
> > + virt_to_gfn(ring->intf), 0);
> > + if (ret < 0)
> > + goto out;
> > + bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
>
> Coding style: (void *)
OK
> > + XEN_9PFS_RING_ORDER - (PAGE_SHIFT - XEN_PAGE_
[PATCH v2 2/5] MIPS: BPF: Add JIT support for SKF_AD_HATYPE.
This let's us pass some additional "modprobe test-bpf" tests with JIT
enabled.
Reuse the code for SKF_AD_IFINDEX, but substitute the offset and size
of the "type" field.
Signed-off-by: David Daney
---
arch/mips/net/bpf_jit.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/mips/net/bpf_jit.c b/arch/mips/net/bpf_jit.c
index 49a2e22..880e329 100644
--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -365,6 +365,12 @@ static inline void emit_half_load(unsigned int reg,
unsigned int base,
emit_instr(ctx, lh, reg, offset, base);
}
+static inline void emit_half_load_unsigned(unsigned int reg, unsigned int base,
+ unsigned int offset, struct jit_ctx
*ctx)
+{
+ emit_instr(ctx, lhu, reg, offset, base);
+}
+
static inline void emit_mul(unsigned int dst, unsigned int src1,
unsigned int src2, struct jit_ctx *ctx)
{
@@ -1112,6 +1118,8 @@ static int build_body(struct jit_ctx *ctx)
break;
case BPF_ANC | SKF_AD_IFINDEX:
/* A = skb->dev->ifindex */
+ case BPF_ANC | SKF_AD_HATYPE:
+ /* A = skb->dev->type */
ctx->flags |= SEEN_SKB | SEEN_A;
off = offsetof(struct sk_buff, dev);
/* Load *dev pointer */
@@ -1120,10 +1128,15 @@ static int build_body(struct jit_ctx *ctx)
emit_bcond(MIPS_COND_EQ, r_s0, r_zero,
b_imm(prog->len, ctx), ctx);
emit_reg_move(r_ret, r_zero, ctx);
- BUILD_BUG_ON(FIELD_SIZEOF(struct net_device,
- ifindex) != 4);
- off = offsetof(struct net_device, ifindex);
- emit_load(r_A, r_s0, off, ctx);
+ if (code == (BPF_ANC | SKF_AD_IFINDEX)) {
+ BUILD_BUG_ON(FIELD_SIZEOF(struct net_device,
ifindex) != 4);
+ off = offsetof(struct net_device, ifindex);
+ emit_load(r_A, r_s0, off, ctx);
+ } else { /* (code == (BPF_ANC | SKF_AD_HATYPE) */
+ BUILD_BUG_ON(FIELD_SIZEOF(struct net_device,
type) != 2);
+ off = offsetof(struct net_device, type);
+ emit_half_load_unsigned(r_A, r_s0, off, ctx);
+ }
break;
case BPF_ANC | SKF_AD_MARK:
ctx->flags |= SEEN_SKB | SEEN_A;
--
2.9.3
Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver
Am 14.03.2017 um 19:08 schrieb Wolfgang Grandegger:
Hello Akshay,
Am 14.03.2017 um 17:20 schrieb Akshay Bhat:
Hi Wolfgang,
On 03/14/2017 08:11 AM, Wolfgang Grandegger wrote:
... snip ...
A few other things to check:
Run "cangen" and monitor the message with "candump -e
any,0:0,#FFF".
Then 1) disconnect the cable or 2) short-circuit CAN low and high
at the
connector. You should see error messages. After reconnection or
removing
the short-circuit (and bus-off recovery) the state should go back to
"active".
With the above sequence, candump reports "ERRORFRAME" with
protocol-violation{{}{acknowledge-slot}}, bus-error. On re-connecting
the cable the can state goes back to ACTIVE and I see the messages that
were in the queue being sent.
Do you get the ACK error also with berr-reporting off? Would be nice if
you could show a candump log here.
Below is a log for disconnecting and re-connecting CAN cable scenario:
(Note this is on a 4.1.18 kernel with RT patch)
root@imx6qrom5420b1:~# ip link set can0 up type can bitrate 100
berr-reporting on
root@imx6qrom5420b1:~# candump -e any,0:0,#FFF &
Please add "-td" ...
[1] 768
root@imx6qrom5420b1:~# cangen can0
and "-i" here.
can0 21C [8] 35 98 C0 7A 95 03 E6 2A
can0 6E6 [1] F2
can0 5C7 [2] 42 50
can0 57C [8] 83 7A E4 0C 03 8B 90 45
can0 55C [8] B9 74 87 52 D8 F4 64 04
can0 014 [8] 28 CB 96 57 3B 80 67 4F
can0 6AF [1] 35
can0 51E [8] B6 C8 6C 1D 3A 87 ED 2E
can0 527 [8] D0 8A D3 59 0E 34 40 78
can0 30C [2] 6A 12
can0 145 [8] CB 6E FF 55 C1 BE C3 22
can0 5A5 [8] C4 49 54 68 02 63 F9 35
can0 0BA [8] DA 57 5E 3A CE 88 20 1C
can0 516 [2] 09 09
can0 743 [8] 7C 4D 25 47 61 4C 56 3D
can0 31D [2] 9C D3
can0 71E [8] 53 7C 97 2A 2A F2 9F 56
can0 52E [8] FE DA 2D 51 73 96 DF 79
/disconnect cable
can0 2088 [8] 00 00 00 19 00 00 28 00 ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
can0 2088 [8] 00 00 00 19 00 00 58 00 ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
can0 2088 [8] 00 00 00 19 00 00 80 00 ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}
TX error warning is missing.
can0 208C [8] 00 20 00 19 00 00 80 00 ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}
Here "tx-error-passiv" is packed with a bus error. What I'm looking for
are state change messages similar to:
can0 2204 [8] 00 08 00 00 00 00 60 00 ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
can0 2204 [8] 00 30 00 00 00 00 80 00 ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}
They should always come, even with "berr-reporting off".
write: No buffer space available
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-PASSIVE (berr-counter tx 128 rx 0)
restart-ms 0
bitrate 100 sample-point 0.750
tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
clock 1600
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 6 0 1 1 0
The error warning and passive counter increased , though. Also the bus
error should come in at a rather hight rate. Looking to the code, maybe
you need to test STATF to check for state changes (and not ERR).
Likely the ERR bits are only valid if the BUSERR bit in INTF is set.
RX: bytes packets errors dropped overrun mcast
0 06 0 0 0
TX: bytes packets errors dropped carrier collsns
10618 0 0 0 0
root@imx6qrom5420b1:~#
/re-connect cable
can0 169 [8] 35 55 A3 1C 0F 47 2E 5B
can0 318 [8] 11 AA 27 11 D2 1B CE 34
can0 577 [8] A0 A4 EE 50 8D A2 E1 3E
can0 4ED [8] 52 96 17 7E 31 FC 7D 7C
can0 2E7 [8] 92 48 D4 39 05 1E 9F 50
can0 200 [8] 4A 66 F6 02 1E 71 8E 26
can0 29A [8] 49 63 2E 7D C9 77 85 7A
can0 15A [7] 3C 0E 65 74 C3 62 80
can0 011 [1] D2
can0 26B [3] FC D6 68
can0 5CE [8] 6F 02 B5 14 BC 7A D7 02
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-ACTIVE (berr-counter tx 117 rx 0)
restart-ms 0
bitrate 100 sample-point 0.750
tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
hi3
Re: [tpmdd-devel] [PATCH] tpm: Add sysfs interface to show TPM hardware version
On Tue, Mar 14, 2017 at 07:58:37PM +0100, Peter Huewe wrote: > >In practice, I suspect that a single user space application won't > >support both TPMs. > Think of init scripts. > Which daemon should it start? Right, ideally we'd have a udev rule that triggers systemd to start the userspace daemons when a TPM is detected, as other hardware does. So whatever format we use has to be compatible with udev's matcher.. Jason
[RESEND PATCH] ARM: omap2: mark omap_init_rng as __init
I found this section mismatch when building with an older
compiler release:
WARNING: vmlinux.o(.text+0x3051c): Section mismatch in reference from the
function omap_init_rng() to the function .init.text:omap_device_build()
Obviously this one function should be __init as well. Normally
we don't get a warning as the function gets inlined into its
caller.
Signed-off-by: Arnd Bergmann
Acked-by: Tony Lindgren
---
Originally submitted on Dec 16. Tony, could you pick it up for v4.12?
We haven't started merging stuff yet, and I forgot to apply it earlier
but want to get it out of my backlog.
---
arch/arm/mach-omap2/devices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3fdb94599184..473951203104 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -121,7 +121,7 @@ static inline void omap_init_mcspi(void) {}
*
* Bind the RNG hwmod to the RNG omap_device. No return value.
*/
-static void omap_init_rng(void)
+static void __init omap_init_rng(void)
{
struct omap_hwmod *oh;
struct platform_device *pdev;
--
2.9.0
Re: [PATCH v4 05/11] mm: thp: enable thp migration in generic path
Hi Naoya, [auto build test ERROR on mmotm/master] [also build test ERROR on next-20170310] [cannot apply to v4.11-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Zi-Yan/mm-page-migration-enhancement-for-thp/20170315-042736 base: git://git.cmpxchg.org/linux-mmotm.git master config: i386-randconfig-s0-201711 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): In file included from fs/proc/task_mmu.c:15:0: include/linux/swapops.h: In function 'remove_migration_pmd': >> include/linux/swapops.h:209:9: warning: 'return' with a value, in function >> returning void return 0; ^ include/linux/swapops.h:205:20: note: declared here static inline void remove_migration_pmd(struct page_vma_mapped_walk *pvmw, ^~~~ -- In file included from mm/page_vma_mapped.c:5:0: include/linux/swapops.h: In function 'remove_migration_pmd': >> include/linux/swapops.h:209:9: warning: 'return' with a value, in function >> returning void return 0; ^ include/linux/swapops.h:205:20: note: declared here static inline void remove_migration_pmd(struct page_vma_mapped_walk *pvmw, ^~~~ In file included from include/asm-generic/bug.h:4:0, from arch/x86/include/asm/bug.h:35, from include/linux/bug.h:4, from include/linux/mmdebug.h:4, from include/linux/mm.h:8, from mm/page_vma_mapped.c:1: In function 'pmd_to_swp_entry.isra.14', inlined from 'page_vma_mapped_walk' at mm/page_vma_mapped.c:149:8: >> include/linux/compiler.h:537:38: error: call to '__compiletime_assert_216' >> declared with attribute error: BUILD_BUG failed _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ include/linux/compiler.h:520:4: note: in definition of macro '__compiletime_assert' prefix ## suffix();\ ^~ include/linux/compiler.h:537:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~ include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ include/linux/bug.h:88:21: note: in expansion of macro 'BUILD_BUG_ON_MSG' #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") ^~~~ >> include/linux/swapops.h:216:2: note: in expansion of macro 'BUILD_BUG' BUILD_BUG(); ^ -- In file included from mm/rmap.c:53:0: include/linux/swapops.h: In function 'remove_migration_pmd': >> include/linux/swapops.h:209:9: warning: 'return' with a value, in function >> returning void return 0; ^ include/linux/swapops.h:205:20: note: declared here static inline void remove_migration_pmd(struct page_vma_mapped_walk *pvmw, ^~~~ In file included from include/asm-generic/bug.h:4:0, from arch/x86/include/asm/bug.h:35, from include/linux/bug.h:4, from include/linux/mmdebug.h:4, from include/linux/mm.h:8, from mm/rmap.c:48: In function 'set_pmd_migration_entry.isra.28', inlined from 'try_to_unmap_one' at mm/rmap.c:1317:5: include/linux/compiler.h:537:38: error: call to '__compiletime_assert_202' declared with attribute error: BUILD_BUG failed _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ include/linux/compiler.h:520:4: note: in definition of macro '__compiletime_assert' prefix ## suffix();\ ^~ include/linux/compiler.h:537:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~ include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ include/linux/bug.h:88:21: note: in expansion of macro 'BUILD_BUG_ON_MSG' #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") ^~~~ include/linux/swapops.h:202:2: note: in expansion of macro 'BUILD_BUG' BUILD_BUG(); ^ -- In file included from mm/migrate.c:18:0: include/linux/swapops.h: In function 'remove_migration_pmd': >> include/linux/swapops.h:209:9: warning: 're
Re: [RESEND PATCH] ARM: omap2: mark omap_init_rng as __init
* Arnd Bergmann [170314 14:27]:
> I found this section mismatch when building with an older
> compiler release:
>
> WARNING: vmlinux.o(.text+0x3051c): Section mismatch in reference from the
> function omap_init_rng() to the function .init.text:omap_device_build()
>
> Obviously this one function should be __init as well. Normally
> we don't get a warning as the function gets inlined into its
> caller.
>
> Signed-off-by: Arnd Bergmann
> Acked-by: Tony Lindgren
> ---
> Originally submitted on Dec 16. Tony, could you pick it up for v4.12?
> We haven't started merging stuff yet, and I forgot to apply it earlier
> but want to get it out of my backlog.
OK will pick it up thanks.
Tony
> ---
> arch/arm/mach-omap2/devices.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 3fdb94599184..473951203104 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -121,7 +121,7 @@ static inline void omap_init_mcspi(void) {}
> *
> * Bind the RNG hwmod to the RNG omap_device. No return value.
> */
> -static void omap_init_rng(void)
> +static void __init omap_init_rng(void)
> {
> struct omap_hwmod *oh;
> struct platform_device *pdev;
> --
> 2.9.0
>
[RESEND PATCH] drm: amd: remove broken include path
The AMD ACP driver adds "-I../acp -I../acp/include" to the gcc command line, which makes no sense, since these are evaluated relative to the build directory. When we build with "make W=1", they instead cause a warning: cc1: error: ../acp/: No such file or directory [-Werror=missing-include-dirs] cc1: error: ../acp/include: No such file or directory [-Werror=missing-include-dirs] cc1: all warnings being treated as errors ../scripts/Makefile.build:289: recipe for target 'drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o' failed ../scripts/Makefile.build:289: recipe for target 'drivers/gpu/drm/amd/amdgpu/amdgpu_device.o' failed ../scripts/Makefile.build:289: recipe for target 'drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o' failed This removes the subdir-ccflags variable that evidently did not serve any purpose here. Signed-off-by: Arnd Bergmann --- Originally submitted in June 2016. All other patches for this warning got merged, once this gets in we can turn on the warning flag for everyone. --- drivers/gpu/drm/amd/acp/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/acp/Makefile b/drivers/gpu/drm/amd/acp/Makefile index 8363cb57915b..8a08e81ee90d 100644 --- a/drivers/gpu/drm/amd/acp/Makefile +++ b/drivers/gpu/drm/amd/acp/Makefile @@ -3,6 +3,4 @@ # of AMDSOC/AMDGPU drm driver. # It provides the HW control for ACP related functionalities. -subdir-ccflags-y += -I$(AMDACPPATH)/ -I$(AMDACPPATH)/include - AMD_ACP_FILES := $(AMDACPPATH)/acp_hw.o -- 2.9.0
[PATCH] [v2] kbuild: disable -ffunction-sections on gcc-4.7 with ftrace
When ftrace is enabled and we build with gcc-4.7 or older, we
get a warning for each file on architectures that select
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION:
warning: -ffunction-sections disabled; it makes profiling impossible [enabled
by default]
This turns off function sections in that specific case, leaving
it enabled for all other configurations.
Fixes: b67067f1176d ("kbuild: allow archs to select link dead code/data
elimination")
Signed-off-by: Arnd Bergmann
Cc: Namhyung Kim
---
Fixed version number in check as pointed out by Namhyung Kim
---
Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile
index 6e7e644a0b84..608727d3e47f 100644
--- a/Makefile
+++ b/Makefile
@@ -662,7 +662,11 @@ KBUILD_CFLAGS += -Wextra
KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
+ifdef CONFIG_FUNCTION_TRACER
+KBUILD_CFLAGS += $(call cc-ifversion, -ge,0409,$(call
cc-option,-ffunction-sections,))
+else
KBUILD_CFLAGS += $(call cc-option,-ffunction-sections,)
+endif
KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
endif
--
2.9.0
[PATCH v4.9] sched/fair: Overload-On-Wakeup fix.
Try improve multi-core scaling.
The changes are experimental - the fix works
but possible regressions are unknown.
Please read the orginal author's paper to understand
the overall problem this patch tries to solve.
See the orignal patches at:
https://github.com/jplozi/wastedcores/tree/master/patches
And the related paper at:
http://www.i3s.unice.fr/~jplozi/wastedcores/
v1: the patch was re-written for v4.9 to remove goto statement.
v2: improved version from the wastedcores initial code. try take into
account the cpu wake-up latency and choose most recent idle cpu
instead.
I have tested the code and it really does improve
multi-core performance on my machine.
Reported-by:
Signed-off-by:
---
kernel/sched/fair.c | 138
1 file changed, 86 insertions(+), 52 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c242944f5cbd..6569e76294d4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5630,6 +5630,10 @@ select_task_rq_fair(struct task_struct *p, int
prev_cpu, int sd_flag, int wake_f
int new_cpu = prev_cpu;
int want_affine = 0;
int sync = wake_flags & WF_SYNC;
+ int chk_cpu;
+ u64 idle_stamp = 0;
+ unsigned int idle_exit_lat = UINT_MAX;
+ int idle_stamp_cpu = -1;
if (sd_flag & SD_BALANCE_WAKE) {
record_wakee(p);
@@ -5638,69 +5642,99 @@ select_task_rq_fair(struct task_struct *p, int
prev_cpu, int sd_flag, int wake_f
}
rcu_read_lock();
- for_each_domain(cpu, tmp) {
- if (!(tmp->flags & SD_LOAD_BALANCE))
- break;
+ /* fast wake up on current idle cpu */
+ if (!cpu_rq(prev_cpu)->nr_running) {
+ new_cpu = prev_cpu;
+ } else {
+ /* Check for suitable unused cores */
+ for_each_cpu_and(chk_cpu, cpu_online_mask, tsk_cpus_allowed(p))
{
+ struct rq *rq = cpu_rq(chk_cpu);
+ struct cpuidle_state *idle = idle_get_state(rq);
- /*
-* If both cpu and prev_cpu are part of this domain,
-* cpu is a valid SD_WAKE_AFFINE target.
-*/
- if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
- cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
- affine_sd = tmp;
- break;
+ if (!rq->nr_running) {
+ if (idle && idle->exit_latency < idle_exit_lat)
{
+ /* Always pick lower latency idle cpu */
+ idle_exit_lat = idle->exit_latency;
+ idle_stamp = rq->idle_stamp;
+ idle_stamp_cpu = chk_cpu;
+ } else if ((!idle || idle->exit_latency ==
idle_exit_lat) &&
+ rq->idle_stamp > idle_stamp) {
+ /* Pick most recent idle cpu. */
+ idle_stamp = rq->idle_stamp;
+ idle_stamp_cpu = chk_cpu;
+ }
+ }
}
- if (tmp->flags & sd_flag)
- sd = tmp;
- else if (!want_affine)
- break;
- }
+ if (idle_stamp_cpu != -1) {
+ /* Found suitable unused cpu */
+ new_cpu = idle_stamp_cpu;
+ } else {
+ /* There was no idle cpus available, must load balance.
*/
+ for_each_domain(cpu, tmp) {
+ if (!(tmp->flags & SD_LOAD_BALANCE))
+ break;
- if (affine_sd) {
- sd = NULL; /* Prefer wake_affine over balance flags */
- if (cpu != prev_cpu && wake_affine(affine_sd, p, prev_cpu,
sync))
- new_cpu = cpu;
- }
+ /* If both cpu and prev_cpu are part of this
domain,
+* cpu is a valid SD_WAKE_AFFINE target.
+*/
+ if (want_affine && (tmp->flags & SD_WAKE_AFFINE)
&&
+ cpumask_test_cpu(prev_cpu,
sched_domain_span(tmp))) {
+ affine_sd = tmp;
+ break;
+ }
+
+ if (tmp->flags & sd_flag)
+ sd = tmp;
+ else if (!want_affine)
+ break;
+ }
- if (!sd) {
- if (sd_flag & SD_BALANCE_WAKE) /* XXX always
[PATCH] [v333kbuild: disable -ffunction-sections on gcc-4.7 with ftrace
When ftrace is enabled and we build with gcc-4.7 or older, we
get a warning for each file on architectures that select
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION:
warning: -ffunction-sections disabled; it makes profiling impossible [enabled
by default]
This turns off function sections in that specific case, leaving
it enabled for all other configurations.
Fixes: b67067f1176d ("kbuild: allow archs to select link dead code/data
elimination")
Signed-off-by: Arnd Bergmann
Cc: Namhyung Kim
---
v2: accidentally resend the same patch as before
v3: actually fixed version number in check as pointed out by Namhyung Kim
---
Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile
index 6e7e644a0b84..608727d3e47f 100644
--- a/Makefile
+++ b/Makefile
@@ -662,7 +662,11 @@ KBUILD_CFLAGS += -Wextra
KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
+ifdef CONFIG_FUNCTION_TRACER
+KBUILD_CFLAGS += $(call cc-ifversion, -ge,0409,$(call
cc-option,-ffunction-sections,))
+else
KBUILD_CFLAGS += $(call cc-option,-ffunction-sections,)
+endif
KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
endif
--
2.9.0
[PATCH] [SUBMITTED 20170314] [v333kbuild: disable -ffunction-sections on gcc-4.7 with ftrace
When ftrace is enabled and we build with gcc-4.7 or older, we
get a warning for each file on architectures that select
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION:
warning: -ffunction-sections disabled; it makes profiling impossible [enabled
by default]
This turns off function sections in that specific case, leaving
it enabled for all other configurations.
Fixes: b67067f1176d ("kbuild: allow archs to select link dead code/data
elimination")
Signed-off-by: Arnd Bergmann
Cc: Namhyung Kim
---
v2: accidentally resend the same patch as before
v3: send the exact same patch once more, without doing the change I wanted
v4: actually fixed version number in check as pointed out by Namhyung Kim (I
hope)
---
Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile
index 6e7e644a0b84..3a964fa3a787 100644
--- a/Makefile
+++ b/Makefile
@@ -662,7 +662,11 @@ KBUILD_CFLAGS += -Wextra
KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
+ifdef CONFIG_FUNCTION_TRACER
+KBUILD_CFLAGS += $(call cc-ifversion, -ge,0408,$(call
cc-option,-ffunction-sections,))
+else
KBUILD_CFLAGS += $(call cc-option,-ffunction-sections,)
+endif
KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
endif
--
2.9.0
[PATCH] [v2] arm64: define BUG() instruction without CONFIG_BUG
This mirrors commit e9c38ceba8d9 ("ARM: 8455/1: define __BUG as
asm(BUG_INSTR) without CONFIG_BUG") to make the behavior of
arm64 consistent with arm and x86, and avoids lots of warnings in
randconfig builds, such as:
kernel/seccomp.c: In function '__seccomp_filter':
kernel/seccomp.c:666:1: error: no return statement in function returning
non-void [-Werror=return-type]
Signed-off-by: Arnd Bergmann
---
Originally submitted v1 on Feb 14 as a simple addition of a few lines.
v2 is a new version doing the same thing with a cleaner rewrite of
the file, using three lines less, after a suggested from Will Deacon.
No need to get this into v4.11 though, especially as the rewrite
makes it a bit risky. Please queue this for v4.12 if you like the
new version.
---
arch/arm64/include/asm/bug.h | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
index 561190d15881..bfc6021760e5 100644
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -20,9 +20,6 @@
#include
-#ifdef CONFIG_GENERIC_BUG
-#define HAVE_ARCH_BUG
-
#ifdef CONFIG_DEBUG_BUGVERBOSE
#define _BUGVERBOSE_LOCATION(file, line) __BUGVERBOSE_LOCATION(file, line)
#define __BUGVERBOSE_LOCATION(file, line) \
@@ -36,28 +33,37 @@
#define _BUGVERBOSE_LOCATION(file, line)
#endif
-#define _BUG_FLAGS(flags) __BUG_FLAGS(flags)
+#ifdef CONFIG_GENERIC_BUG
-#define __BUG_FLAGS(flags) asm volatile ( \
+#define __BUG_ENTRY(flags) \
".pushsection __bug_table,\"a\"\n\t"\
".align 2\n\t" \
"0: .long 1f - 0b\n\t" \
_BUGVERBOSE_LOCATION(__FILE__, __LINE__) \
".short " #flags "\n\t" \
".popsection\n" \
- \
- "1: brk %[imm]" \
- :: [imm] "i" (BUG_BRK_IMM) \
-)
+ "1: "
+#else
+#define __BUG_ENTRY(flags) ""
+#endif
+
+#define __BUG_FLAGS(flags) \
+ asm volatile ( \
+ __BUG_ENTRY(0) \
+ "brk %[imm]" :: [imm] "i" (BUG_BRK_IMM) \
+ );
-#define BUG() do { \
- _BUG_FLAGS(0); \
- unreachable(); \
+#define _BUG_FLAGS(flags) __BUG_FLAGS(flags)
+
+#define BUG() do { \
+ __BUG_FLAGS(0); \
+ unreachable(); \
} while (0)
-#define __WARN_TAINT(taint) _BUG_FLAGS(BUGFLAG_TAINT(taint))
+#define __WARN_TAINT(taint)\
+ __BUG_FLAGS(BUGFLAG_TAINT(taint))
-#endif /* ! CONFIG_GENERIC_BUG */
+#define HAVE_ARCH_BUG
#include
--
2.9.0
[PATCH] tpm: select CONFIG_CRYPTO
As we need the CRYPTO_HASH_INFO implementation, we should also
select CRYPTO itself to avoid this build warning:
warning: (TCG_TPM && TRUSTED_KEYS && IMA) selects CRYPTO_HASH_INFO which has
unmet direct dependencies (CRYPTO)
Fixes: c1f92b4b04ad ("tpm: enhance TPM 2.0 PCR extend to support multiple
banks")
Signed-off-by: Arnd Bergmann
---
drivers/char/tpm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index af985cca413c..d520ac51c11c 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -6,6 +6,7 @@ menuconfig TCG_TPM
tristate "TPM Hardware Support"
depends on HAS_IOMEM
select SECURITYFS
+ select CRYPTO
select CRYPTO_HASH_INFO
---help---
If you have a TPM security chip in your system, which
--
2.9.0
Re: [tpmdd-devel] [PATCH] tpm: Add sysfs interface to show TPM hardware version
On Tue, 2017-03-14 at 15:24 -0600, Jason Gunthorpe wrote: > On Tue, Mar 14, 2017 at 07:58:37PM +0100, Peter Huewe wrote: > > > > In practice, I suspect that a single user space application won't > > > support both TPMs. > > Think of init scripts. > > Which daemon should it start? > > Right, ideally we'd have a udev rule that triggers systemd to start > the userspace daemons when a TPM is detected, as other hardware does. > > So whatever format we use has to be compatible with udev's matcher.. Technically, we have that already: my TPM2.0 detection stuff for udev triggers off the presence of the SUBSYSTEM=="tpmrm" that matches any TPM2 device but not a 1.x one. James
[PATCH] [v2] mtd: spi-nor: don't include linux/mtd/cfi.h from header
The newly added broadcom qspi driver in drivers/spi produces a build
warning when CONFIG_MTD is disabled:
include/linux/mtd/cfi.h:76:2: #warning No CONFIG_MTD_CFI_Ix selected. No NOR
chip support can work. [-Werror=cpp]
Since drivers like this one don't actually need the cfi.h header,
we can just remove it from the spi-nor.h file and add it to
the only place that actually needs it.
Fixes: fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver")
Link: https://patchwork.kernel.org/patch/9334097/
Signed-off-by: Arnd Bergmann
---
v2: move definitions as suggested by Ezequiel
---
drivers/mtd/spi-nor/spi-nor.c | 16
include/linux/mtd/spi-nor.h | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 747645c74134..7d7ad84f739f 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -21,8 +21,24 @@
#include
#include
#include
+#include
#include
+/*
+ * Manufacturer IDs
+ *
+ * The first byte returned from the flash after sending opcode SPINOR_OP_RDID.
+ * Sometimes these are the same as CFI IDs, but sometimes they aren't.
+ */
+#define SNOR_MFR_ATMEL CFI_MFR_ATMEL
+#define SNOR_MFR_GIGADEVICE0xc8
+#define SNOR_MFR_INTEL CFI_MFR_INTEL
+#define SNOR_MFR_MICRONCFI_MFR_ST /* ST Micro <--> Micron */
+#define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX
+#define SNOR_MFR_SPANSION CFI_MFR_AMD
+#define SNOR_MFR_SST CFI_MFR_SST
+#define SNOR_MFR_WINBOND 0xef /* Also used by some Spansion */
+
/* Define max times to check status register before we give up. */
/*
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index f2a718030476..716a8f79784e 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -11,25 +11,9 @@
#define __LINUX_MTD_SPI_NOR_H
#include
-#include
#include
/*
- * Manufacturer IDs
- *
- * The first byte returned from the flash after sending opcode SPINOR_OP_RDID.
- * Sometimes these are the same as CFI IDs, but sometimes they aren't.
- */
-#define SNOR_MFR_ATMEL CFI_MFR_ATMEL
-#define SNOR_MFR_GIGADEVICE0xc8
-#define SNOR_MFR_INTEL CFI_MFR_INTEL
-#define SNOR_MFR_MICRONCFI_MFR_ST /* ST Micro <--> Micron */
-#define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX
-#define SNOR_MFR_SPANSION CFI_MFR_AMD
-#define SNOR_MFR_SST CFI_MFR_SST
-#define SNOR_MFR_WINBOND 0xef /* Also used by some Spansion */
-
-/*
* Note on opcode nomenclature: some opcodes have a format like
* SPINOR_OP_FUNCTION{4,}_x_y_z. The numbers x, y, and z stand for the number
* of I/O lines used for the opcode, address, and data (respectively). The
--
2.9.0
Re: [PATCH v15 6/9] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
Kyle,
your patch format is really odd.
You seem to have *eight* lines of context rather than the regular 3.
Is there any reason for that oddity?
It basically means that a one-line hunk ends up being 17 lines of
unified diff rather than 7.
Example appended,
Linus
On Sat, Mar 11, 2017 at 11:46 AM, Kyle Huey wrote:
>
> diff --git a/arch/x86/include/asm/thread_info.h
> b/arch/x86/include/asm/thread_info.h
> index ad6f5eb07a95..9fc44b95f7cb 100644
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -82,16 +82,17 @@ struct thread_info {
> #define TIF_SIGPENDING 2 /* signal pending */
> #define TIF_NEED_RESCHED 3 /* rescheduling necessary */
> #define TIF_SINGLESTEP 4 /* reenable singlestep on user
> return*/
> #define TIF_SYSCALL_EMU6 /* syscall emulation active */
> #define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
> #define TIF_SECCOMP8 /* secure computing */
> #define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return
> */
> #define TIF_UPROBE 12 /* breakpointed or singlestepping */
> +#define TIF_NOCPUID15 /* CPUID is not accessible in
> userland */
> #define TIF_NOTSC 16 /* TSC is not accessible in userland
> */
> #define TIF_IA32 17 /* IA32 compatibility process */
> #define TIF_NOHZ 19 /* in adaptive nohz mode */
> #define TIF_MEMDIE 20 /* is terminating due to OOM killer */
> #define TIF_POLLING_NRFLAG 21 /* idle is polling for
> TIF_NEED_RESCHED */
> #define TIF_IO_BITMAP 22 /* uses I/O bitmap */
> #define TIF_FORCED_TF 24 /* true if TF in eflags artificially
> */
> #define TIF_BLOCKSTEP 25 /* set when we want DEBUGCTLMSR_BTF */
Re: [PATCH RESEND v1] locking/ww_mutex: Prevent read of uninitialized memory
On Tue, Mar 14, 2017 at 03:44:02PM -0400, Robert Foss wrote:
> On "missed ABBA deadlock" abba.result is read, but not initialized
> in all situations.
>
> Detected by CoverityScan, CID#1402035 ("Uninitialized scalar variable")
It's unconditionally set by the worker, and only accessed by the parent
after the flush_work() barrier.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH] initramfs: use vfs_stat/lstat directly
sys_newlstat is a system call implementation that is meant for user
space, and that copies kernel-internal data structure to the user
format, which is not needed for in-kernel users.
Further, as we rearrange the system call implementation so we can
extend it with 64-bit time_t, the prototype for sys_newlstat changes.
This changes the initramfs code to use vfs_lstat directly, to get
it out of the way of the time_t changes, and make it slightly more
efficient in the process. Along the same lines we also replace
sys_stat and sys_stat64 with vfs_stat.
Signed-off-by: Arnd Bergmann
---
Submitted before in June 2016, but no reply.
Andrew or Al, could one of you pick this up for v4.12?
---
init/do_mounts.h | 22 --
init/initramfs.c | 12 ++--
2 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/init/do_mounts.h b/init/do_mounts.h
index 067af1d9e8b6..282d65bfd674 100644
--- a/init/do_mounts.h
+++ b/init/do_mounts.h
@@ -19,29 +19,15 @@ static inline int create_dev(char *name, dev_t dev)
return sys_mknod(name, S_IFBLK|0600, new_encode_dev(dev));
}
-#if BITS_PER_LONG == 32
static inline u32 bstat(char *name)
{
- struct stat64 stat;
- if (sys_stat64(name, &stat) != 0)
+ struct kstat stat;
+ if (vfs_stat(name, &stat) != 0)
return 0;
- if (!S_ISBLK(stat.st_mode))
+ if (!S_ISBLK(stat.mode))
return 0;
- if (stat.st_rdev != (u32)stat.st_rdev)
- return 0;
- return stat.st_rdev;
-}
-#else
-static inline u32 bstat(char *name)
-{
- struct stat stat;
- if (sys_newstat(name, &stat) != 0)
- return 0;
- if (!S_ISBLK(stat.st_mode))
- return 0;
- return stat.st_rdev;
+ return stat.rdev;
}
-#endif
#ifdef CONFIG_BLK_DEV_RAM
diff --git a/init/initramfs.c b/init/initramfs.c
index 7eb7cb7cb9b9..83d514d0e69d 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -312,10 +312,10 @@ static int __init maybe_link(void)
static void __init clean_path(char *path, umode_t fmode)
{
- struct stat st;
+ struct kstat st;
- if (!sys_newlstat(path, &st) && (st.st_mode ^ fmode) & S_IFMT) {
- if (S_ISDIR(st.st_mode))
+ if (!vfs_lstat(path, &st) && (st.mode ^ fmode) & S_IFMT) {
+ if (S_ISDIR(st.mode))
sys_rmdir(path);
else
sys_unlink(path);
@@ -581,13 +581,13 @@ static void __init clean_rootfs(void)
num = sys_getdents64(fd, dirp, BUF_SIZE);
while (num > 0) {
while (num > 0) {
- struct stat st;
+ struct kstat st;
int ret;
- ret = sys_newlstat(dirp->d_name, &st);
+ ret = vfs_lstat(dirp->d_name, &st);
WARN_ON_ONCE(ret);
if (!ret) {
- if (S_ISDIR(st.st_mode))
+ if (S_ISDIR(st.mode))
sys_rmdir(dirp->d_name);
else
sys_unlink(dirp->d_name);
--
2.9.0
[PATCH] dax: fix regression in dax_writeback_mapping_range()
commit 354ae7432ee8 ("dax: add tracepoints to dax_writeback_mapping_range()")
in the -next tree, which appears in next-20170310, inadvertently changed
dax_writeback_mapping_range() so that it could end up returning a positive
value: the number of bytes flushed, as returned by dax_writeback_one().
This was incorrect. This function either needs to return a negative error
value, or zero on success.
This change was causing xfstest failures, as reported by Xiong:
https://lkml.org/lkml/2017/3/13/1220
With this fix applied to next-20170310, all the test failures reported by
Xiong (generic/075 generic/112 generic/127 generic/231 generic/263) are
resolved.
Reported-by: Xiong Zhou
Signed-off-by: Ross Zwisler
---
fs/dax.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/dax.c b/fs/dax.c
index 1861ef0..60688c7 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -907,7 +907,7 @@ int dax_writeback_mapping_range(struct address_space
*mapping,
}
out:
trace_dax_writeback_range_done(inode, start_index, end_index);
- return ret;
+ return (ret < 0 ? ret : 0);
}
EXPORT_SYMBOL_GPL(dax_writeback_mapping_range);
--
2.9.3
firm-ware download
Hello all, I wanted to find out if udev is involved in loading of the firmware during the booting up of the kernel. Usually firmware download is done during the bootup of the kernel. In that case, the udev monitors are not running. How do the firmware get downloaded? Thanks, ryan
Re: [PATCH v4 05/11] mm: thp: enable thp migration in generic path
On 03/14/2017 04:19 PM, kbuild test robot wrote:
> Hi Naoya,
>
> [auto build test WARNING on mmotm/master]
> [also build test WARNING on next-20170310]
> [cannot apply to v4.11-rc2]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Zi-Yan/mm-page-migration-enhancement-for-thp/20170315-042736
> base: git://git.cmpxchg.org/linux-mmotm.git master
> config: m68k-sun3_defconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 4.9.0
> reproduce:
> wget
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=m68k
>
> All warnings (new ones prefixed by >>):
>
>In file included from fs/proc/task_mmu.c:15:0:
>include/linux/swapops.h: In function 'remove_migration_pmd':
>include/linux/swapops.h:209:2: warning: 'return' with a value, in function
> returning void
> return 0;
> ^
>include/linux/swapops.h: In function 'swp_entry_to_pmd':
I will remove "return 0;" in next version.
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -208,7 +208,6 @@ static inline void remove_migration_pmd(struct
page_vma_mapped_walk *pvmw,
struct page *new)
{
BUILD_BUG();
- return 0;
}
static inline void pmd_migration_entry_wait(struct mm_struct *m, pmd_t
*p) { }
>>> include/linux/swapops.h:223:2: warning: missing braces around initializer
>>> [-Wmissing-braces]
> return (pmd_t){ 0 };
> ^
>include/linux/swapops.h:223:2: warning: (near initialization for
> '(anonymous).pmd') [-Wmissing-braces]
I do not have any warning with gcc 6.3.0. This seems to be a GCC bug
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119).
--
Best Regards,
Yan Zi
signature.asc
Description: OpenPGP digital signature
Re: [OpenRISC] [PATCH 3/3] openrisc: Export symbols needed by modules
On Tue, Mar 14, 2017 at 04:25:30PM +0100, Geert Uytterhoeven wrote:
> Hi Stafford,
>
> On Tue, Mar 14, 2017 at 3:56 PM, Stafford Horne wrote:
> > This was detected by allmodconfig, errors reported:
> >
> > ERROR: "empty_zero_page" [net/ceph/libceph.ko] undefined!
> > ERROR: "__ucmpdi2" [lib/842/842_decompress.ko] undefined!
> > ERROR: "empty_zero_page" [fs/nfs/objlayout/objlayoutdriver.ko] undefined!
> > ERROR: "empty_zero_page" [fs/exofs/exofs.ko] undefined!
> > ERROR: "empty_zero_page" [fs/crypto/fscrypto.ko] undefined!
> > ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined!
> > ERROR: "pm_power_off" [drivers/regulator/act8865-regulator.ko] undefined!
> >
> > Signed-off-by: Stafford Horne
>
> > --- a/arch/openrisc/kernel/or32_ksyms.c
> > +++ b/arch/openrisc/kernel/or32_ksyms.c
> > @@ -42,6 +42,11 @@ DECLARE_EXPORT(__muldi3);
> > DECLARE_EXPORT(__ashrdi3);
> > DECLARE_EXPORT(__ashldi3);
> > DECLARE_EXPORT(__lshrdi3);
> > +DECLARE_EXPORT(__ucmpdi2);
> > +
> > +extern unsigned long empty_zero_page[2048];
>
> Can't you #include instead of adding a forward
> declaration?
Right, I can do this.
In the end I was hoping to convert empty_zero_page to be more like
parisc. which would put something like this mm/init.c
unsigned long *empty_zero_page __read_mostly;
EXPORT_SYMBOL(empty_zero_page);
in init {
empty_zero_page = get_memblock(PAGE_SIZE);
}
But I was going to wait until 4.12 for that change.
-Stafford
> > +EXPORT_SYMBOL(empty_zero_page);
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Infinite loop when connecting to unreachable NFS servers
Hi,
I was debugging some mysterious high CPU usage and tracked it down to
monitoring daemon regularly calling stat*() on an NFS automount
directory. The problem is triggered when mount.nfs passes mount() an
addr= that points to an unreachable address (i.e. connecting fails
immediately).
One way to reproduce is by trying to mount Google's DNS server, whose
IPv6 address isn't properly parsed or rejected by nfs-utils, causing an
invalid addr= to be passed to mount():
# strace -vf mount.nfs -v 2001:4860:4860:0:0:0:0::/ /mnt
write(1, "mount.nfs: timeout set for Tue Mar 14 22:57:49 2017", ...
[...]
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")},
16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("0.0.7.209")}, 16) = -1 EINVAL (Invalid argument)
close(3)= 0
write(1, "mount.nfs: trying text-based options
'vers=4.2,addr=0.0.7.209,clientaddr=0.0.0.0'", ...
mount("2001:4860:4860:0:0:0:0::/", "/mnt", "nfs", 0,
"vers=4.2,addr=0.0.7.209,clientad"...) = ?
+++ killed by SIGKILL +++
While this is certainly a bug in mount.nfs, too, the bug can also be
triggered with net.conf.ipv6.all.disable_ipv6=1 and using a hostname that
resolves to an IPv6 address only (/etc/hosts works) with mount.nfs.
<4>[ 6564.082853] RPC: 8 sleep_on(queue "xprt_pending" time 4296533344)
<4>[ 6564.082855] RPC: 8 added to queue 8a673b146a18 "xprt_pending"
<4>[ 6564.082858] RPC: 8 setting alarm for 18 ms
<4>[ 6564.082860] RPC: xs_connect scheduled xprt 8a673b146800
<4>[ 6564.082863] RPC: 8 sync task going to sleep
<4>[ 6564.082868] RPC: xs_bind
::::::::784: ok (0)
<4>[ 6564.082870] RPC: worker connecting xprt 8a673b146800 via tcp to
2001:4860:4860:: (port 2049)
<4>[ 6564.082874] RPC: 8a673b146800 connect status 99 connected 0
sock state 7
<4>[ 6564.082876] RPC: 8 __rpc_wake_up_task (now 4296533344)
<4>[ 6564.082878] RPC: 8 disabling timer
<4>[ 6564.082880] RPC: 8 removed from queue 8a673b146a18 "xprt_pending"
<4>[ 6564.082883] RPC: __rpc_wake_up_task done
<4>[ 6564.082885] RPC: xs_tcp_state_change client 8a673b146800...
<4>[ 6564.082887] RPC: state 7 conn 0 dead 0 zapped 1 sk_shutdown 3
<4>[ 6564.082889] RPC: disconnected transport 8a673b146800
<4>[ 6564.082893] RPC: wake_up_first(8a673b146970 "xprt_sending")
<4>[ 6564.082897] RPC: 8 sync task resuming
<4>[ 6564.082899] RPC: 8 xprt_connect_status: retrying
<4>[ 6564.082901] RPC: 8 call_connect_status (status -11)
<4>[ 6564.082903] RPC: 8 call_timeout (minor)
<4>[ 6564.082905] RPC: 8 call_bind (status 0)
<4>[ 6564.082907] RPC: 8 call_connect xprt 8a673b146800 is not connected
<4>[ 6564.082909] RPC: 8 xprt_connect xprt 8a673b146800 is not connected
<4>[ 6564.082912] RPC: 8 sleep_on(queue "xprt_pending" time 4296533344)
<4>[ 6564.082913] RPC: 8 added to queue 8a673b146a18 "xprt_pending"
<4>[ 6564.082914] RPC: 8 setting alarm for 18 ms
<4>[ 6564.082914] RPC: xs_connect scheduled xprt 8a673b146800
<4>[ 6564.082916] RPC: 8 sync task going to sleep
<4>[ 6564.082919] RPC: xs_bind
::::::::938: ok (0)
<4>[ 6564.082920] RPC: worker connecting xprt 8a673b146800 via tcp to
2001:4860:4860:: (port 2049)
<4>[ 6564.082923] RPC: 8a673b146800 connect status 99 connected 0
sock state 7
<4>[ 6564.082924] RPC: 8 __rpc_wake_up_task (now 4296533344)
<4>[ 6564.082924] RPC: 8 disabling timer
(and so on, until mount() times out)
Similar for the IPv6-literal test case, where it's failing to connect to
0.0.7.209, so it's affecting IPv4, too. While grepping around I found a
comment saying "If a UDP socket connect fails, the delay behavior here
prevents retry floods (hard mounts)." for xs_connect(), but I haven't
figured out how to trigger the UDP connection code.
Sebastian
signature.asc
Description: PGP signature
Re: [PATCH v2 0/5] MIPS: BPF: JIT fixes and improvements.
On 03/14/2017 10:21 PM, David Daney wrote: Changes from v1: - Use unsigned access for SKF_AD_HATYPE - Added three more patches for other problems found. Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module identified some failures and unimplemented features. Nice, thanks for working on this! If you see specific test cases for the JIT missing, please also feel free to extend the test_bpf suite, so this gets exposed further to other JITs, too. With this patch set we get: test_bpf: Summary: 305 PASSED, 0 FAILED, [85/297 JIT'ed] Both big and little endian tested. We still lack eBPF support, but this is better than nothing. Any future plans on this one? Thanks, Daniel
Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR
On Tue, Mar 14, 2017 at 4:48 PM, Filip Štědronský wrote: > Hi, > > On Tue, Mar 14, 2017 at 03:55:19PM +0200, Amir Goldstein wrote: >> Please let me know if that is sufficient for your needs >> or if you need me to prepare a version that delivers filename events >> without filename info, therefore allowing to merge filename events. >> >> Sounds to me like if you get an event FAN_DELETE, "aaa", >> your implementation can update the db directly without having >> to scan the directory, so it should be useful. >> For your consideration. > > both approaches might be useful and there are tradeoffs. Direct updates > save us from rescanning but give more events and more context switches. > > On the other hand, with an unlimited queue and well-mergable events I > could e.g. sleep for five seconds each time after emptying the queue, > thus giving the events more potential to merge and reducing context > switches. > > But one risks blowing up the queue. However, I have some ideas. > Basically we could implement some kind of "bulk read" mode for fanotify > that would pass events to userspace only when > (a) a given event count thresold is hit (e.g. half the queue limit > if queue is limited), or > (b) the oldest event is older than a specified maximum latency. That > might vary from 1 second to 5 minutes depending on specific > application needs (e.g. background backup does not need to be > low-latency). > > This would greatly reduce extra context switches when watching > a large portion (or whole) of the file system. All of this presumably > could be implemented on top of your suggested patches. > > Either way, I suggest that implementing the nameless filename events > is a good idea. I do not know whether they will be the best choice > for my application but they probably will be useful for some > applications. > Done and pushed all branches. Added 2 new patches to the fanotify_dentry set: ce0c223 fanotify: allow merge of filename events cd872d1 fanotify: make filename info optional for filename events You should test with branch fanotify_sb, using super block watch, because filename events are not supported in mount scope. You can follow user API used by my fanotify_demo.c program. Tested with my fanotify_demo test both without FAN_EVENT_INFO_NAME and without FAN_EVENT_INFO_FH. Without FAN_EVENT_INFO_NAME more filename events are merged, but in my test that runs fs ops by a script, most events do not get merged because of different pid value. I guess that for the filesync/indexer use case, we would need to add a new FAN_EVENT_INFO_NOPID flag to loose the irrelevant pid information in order to be able to merge a lot more filename event on a directory. I also plan to add FAN_EVENT_INFO_NOFD, to get rid of redundant fd (when INFO_FH is available) and then be able to drop the refcount on the victim object. Cheers, Amir.
media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)
Hi! > > > Even if they were merged, if we keep the same mean time to develop a > > > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3 > > > years to be developed. > > > > > > There's a clear message on it: > > > - we shouldn't keep pushing for a solution via libv4l. > > > > Or: > > > > - userspace plugin development had a very a low priority and > > never got the attention it needed. > > The end result is the same: we can't count on it. > > > > > I know that's *my* reason. I rarely if ever looked at it. I always assumed > > Sakari and/or Laurent would look at it. If this reason is also valid for > > Sakari and Laurent, then it is no wonder nothing has happened in all that > > time. > > > > We're all very driver-development-driven, and userspace gets very little > > attention in general. So before just throwing in the towel we should take > > a good look at the reasons why there has been little or no development: is > > it because of fundamental design defects, or because nobody paid attention > > to it? > > No. We should look it the other way: basically, there are patches > for i.MX6 driver that sends control from videonode to subdevs. > > If we nack apply it, who will write the userspace plugin? When > such change will be merged upstream? Well, I believe first question is: what applications would we want to run on complex devices? Will sending control from video to subdevs actually help? mplayer is useful for testing... but that one already works (after you setup the pipeline, and configure exposure/gain). But thats useful for testing, not really for production. Image will be out of focus and with wrong white balance. What I would really like is an application to get still photos. For taking pictures with manual settings we need a) units for controls: user wants to focus on 1m, and take picture with ISO200, 1/125 sec. We should also tell him that lens is f/5.6 and focal length is 20mm with 5mm chip. But... autofocus/autogain would really be good to have. Thus we need: b) for each frame, we need exposure settings and focus position at time frame was taken. Otherwise autofocus/autogain will be too slow. At least focus position is going to be tricky -- either kernel would have to compute focus position for us (not trivial) or we'd need enough information to compute it in userspace. There are more problems: hardware-accelerated preview is not trivial to set up (and I'm unsure if it can be done in generic way). Still photos application needs to switch resolutions between preview and photo capture. Probably hardware-accelerated histograms are needed for white balance, auto gain and auto focus, It seems like there's a _lot_ of stuff to be done before we have useful support for complex cameras... (And I'm not sure... when application such as skype is running, is there some way to run autogain/autofocus/autowhitebalance? Is that something we want to support?) > If we don't have answers to any of the above questions, we should not > nack it. > > That's said, that doesn't prevent merging a libv4l plugin if/when > someone can find time/interest to develop it. I believe other question is: will not having same control on main video device and subdevs be confusing? Does it actually help userspace in any way? Yes, we can make controls accessible to old application, but does it make them more useful? > > In addition, I suspect end-users of these complex devices don't really care > > about a plugin: they want full control and won't typically use generic > > applications. If they would need support for that, we'd have seen much more > > interest. The main reason for having a plugin is to simplify testing and > > if this is going to be used on cheap hobbyist devkits. > > What are the needs for a cheap hobbyist devkit owner? Do we currently > satisfy those needs? I'd say that having a functional driver when > compiled without the subdev API, that implements the ioctl's/controls Having different interface based on config options... is just weird. What about poor people (like me) trying to develop complex applications? > [1] Yet, I might eventually do that for fun, an OMAP3 board with tvp5150 > just arrived here last week. It would be nice to have xawtv3 running on it :-) > So, if I have a lot of spare time (with is very unlikely), I might eventually > do something for it to work. > > > I know it took me a very long time before I had a working omap3. > > My first OMAP3 board with working V4L2 source just arrived last week > :-) You can get Nokia N900 on aliexpress. If not, they are still available between people :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v2 0/5] MIPS: BPF: JIT fixes and improvements.
On 03/14/2017 03:29 PM, Daniel Borkmann wrote: On 03/14/2017 10:21 PM, David Daney wrote: Changes from v1: - Use unsigned access for SKF_AD_HATYPE - Added three more patches for other problems found. Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module identified some failures and unimplemented features. Nice, thanks for working on this! If you see specific test cases for the JIT missing, please also feel free to extend the test_bpf suite, so this gets exposed further to other JITs, too. With this patch set we get: test_bpf: Summary: 305 PASSED, 0 FAILED, [85/297 JIT'ed] Both big and little endian tested. We still lack eBPF support, but this is better than nothing. Any future plans on this one? Yes, my plan is to fully implement eBPF support for 64-bit MIPS, let's see if I get enough time to do it. David.
mmotm 2017-03-14-15-41 uploaded
The mm-of-the-moment snapshot 2017-03-14-15-41 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (4.x or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 4.11-rc2: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch * z3fold-fix-spinlock-unlocking-in-page-reclaim.patch * kasan-add-a-prototype-of-task_struct-to-avoid-warning.patch * mm-x86-fix-native_pud_clear-build-error.patch * mm-dont-warn-when-vmalloc-fails-due-to-a-fatal-signal.patch * mm-add-private-lock-to-serialize-memory-hotplug-operations.patch * drivers-core-remove-assert_held_device_hotplug.patch * arm-arch-arm-include-asm-pageh-needs-personalityh.patch * dax-add-tracepoints-to-dax_iomap_pte_fault.patch * dax-add-tracepoints-to-dax_pfn_mkwrite.patch * dax-add-tracepoints-to-dax_load_hole.patch * dax-add-tracepoints-to-dax_writeback_mapping_range.patch * dax-add-tracepoints-to-dax_writeback_mapping_range-fix.patch * dax-add-tracepoint-to-dax_writeback_one.patch * dax-add-tracepoint-to-dax_insert_mapping.patch * fs-ocfs2-cluster-use-setup_timer.patch * ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called.patch * ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix.patch * ocfs2-dlm-optimization-of-code-while-free-dead-node-locks.patch * ocfs2-dlm-optimization-of-code-while-free-dead-node-locks-checkpatch-fixes.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch mm.patch * mm-fix-100%-cpu-kswapd-busyloop-on-unreclaimable-nodes.patch * mm-fix-100%-cpu-kswapd-busyloop-on-unreclaimable-nodes-fix.patch * mm-fix-100%-cpu-kswapd-busyloop-on-unreclaimable-nodes-fix-2.patch * mm-fix-check-for-reclaimable-pages-in-pf_memalloc-reclaim-throttling.patch * mm-remove-seemingly-spurious-reclaimability-check-from-laptop_mode-gating.patch * mm-remove-unnecessary-reclaimability-check-from-numa-balancing-target.patch * mm-dont-avoid-high-priority-reclaim-on-unreclaimable-nodes.patch * mm-dont-avoid-high-priority-reclaim-on-memcg-limit-reclaim.patch * mm-delete-nr_pages_scanned-and-pgdat_reclaimable.patch * revert-mm-vmscan-account-for-skipped-pages-as-a-partial-scan.patch * mm-remove-unnecessary-back-off-function-when-retrying-page-reclaim.patch * writeback-use-setup_deferrable_timer.patch * mm-delete-unnecessary-ttu_-flags.patch * mm-dont-assume-anonymous-pages-have-swapbacked-flag.patch * mm-move-madv_free-pages-into-lru_inactive_file-list.patch * mm-move-madv_free-pages-into-lru_inactive_file-list-checkpatch-fixes.patch * mm-reclaim-madv_free-pages.patch * mm-reclaim-madv_free-pages-fix.patch * mm-fix-lazyfree-bug-on-check-in-try_to_unmap_one.patch * mm-fix-lazyfree-bug-on-check-in-try_to_unmap_one-fix.patch * mm-enable-madv_fr
Re: [tpmdd-devel] [PATCH] vTPM: Fix missing NULL check
On Wed, 2017-03-08 at 13:52 -0700, Jason Gunthorpe wrote: > On Wed, Mar 08, 2017 at 03:28:11PM -0500, Hon Ching(Vicky) Lo wrote: > > On Wed, 2017-03-08 at 10:17 -0700, Jason Gunthorpe wrote: > > > On Tue, Mar 07, 2017 at 11:12:43PM -0500, Hon Ching(Vicky) Lo wrote: > > > > On Mon, 2017-03-06 at 16:19 -0700, Jason Gunthorpe wrote: > > > > > > > > Also, how does locking work here? Does the vio core prevent > > > > > tpm_ibmvtpm_get_desired_dma and tpm_ibmvtpm_remove from running > > > > > concurrently? > > > > > > > > No, vio core doesn't prevent tpm_ibmvtpm_get_desired_dma and > > > > tpm_ibmvtpm_remove > > > > from running concurrently. > > > > > > > > vio_bus_probe calls vio_cmo_bus_probe which calls > > > > tpm_ibmvtpm_get_desired_dma. > > > > tpm_ibmvtpm_get_desired_dma is called before the code enters critical > > > > section. > > > > > > > > There is no locking mechanism around tpm_ibmvtpm_remove in > > > > vio_bus_remove. > > > > > > > > What's the concern here? > > > > > > tpm_ibmvtpm_remove makes the pointer that tpm_ibmvtpm_get_desired_dma > > > is accessing invalid, so some kind of locking is technically required > > > so that the two things do not create a use after free race: > > > > I don't think we need to worry about locking in this specific case. > > tpm_ibmvtpm_get_desired_dma was designed to return a default value > > in the case when the chip is not available. > > You have to worry about it to prevent a use after free race: > > CPU0CPU1 > tpm_ibmvtpm_remove() tpm_ibmvtpm_get_desired_dma() > >chip = dev_get_drvdata(dev); > dev_set_drvdata(&vdev->dev, NULL); > if (chip) > ibmvtpm = dev_get_drvdata(&chip->dev); > kfree(ibmvtpm); > // *ibmvtpm is now a use-after-free > > Jason > I have dug further up along the call stack of tpm_ibmvtpm_get_desired_dma() and found that there is a locking mechanism in place at the bus probe level. 'probe' and 'remove' callbacks are both surrounded by mutex_lock and mutex_unlock on the device. The code is in the really_probe() and device_release_driver_internal() accordingly. Thanks for pointing this out! Vicky
Re: [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit
,"Luis R . Rodriguez" ,Stanislaw Gruszka ,Peter Zijlstra ,Josh Poimboeuf ,Vitaly Kuznetsov ,Tim Chen ,Joerg Roedel , TF-8?B?UmFkaW0gS3LEjW3DocWZ?From: h...@zytor.com Message-ID: <550f6209-025a-45e2-84e2-f00a3771c...@zytor.com> On March 14, 2017 2:20:19 PM PDT, Thomas Garnier wrote: >On Tue, Mar 14, 2017 at 2:04 PM, Pavel Machek wrote: >> On Tue 2017-03-14 10:05:08, Thomas Garnier wrote: >>> This patch makes the GDT remapped pages read-only to prevent >corruption. >>> This change is done only on 64-bit. >>> >>> The native_load_tr_desc function was adapted to correctly handle a >>> read-only GDT. The LTR instruction always writes to the GDT TSS >entry. >>> This generates a page fault if the GDT is read-only. This change >checks >>> if the current GDT is a remap and swap GDTs as needed. This function >was >>> tested by booting multiple machines and checking hibernation works >>> properly. >>> >>> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the >>> per-cpu variable was removed for functions to fetch the original >GDT. >>> Instead of reloading the previous GDT, VMX will reload the fixmap >GDT as >>> expected. For testing, VMs were started and restored on multiple >>> configurations. >>> >>> Signed-off-by: Thomas Garnier >> >> Can we get the same change for 32-bit, too? Growing differences >> between 32 and 64 bit are a bit of a problem... >> Pavel > >It was discussed on previous versions that 32-bit read-only support >would create issues that why it was favor for 64-bit only right now. > >> >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) >http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html We can't make the GDT read-only on 32 bits since we use task switches for last-resort recovery. 64 bits has IST instead. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH v2 0/5] MIPS: BPF: JIT fixes and improvements.
On Tue, Mar 14, 2017 at 02:21:39PM -0700, David Daney wrote: > Changes from v1: > > - Use unsigned access for SKF_AD_HATYPE > > - Added three more patches for other problems found. > > > Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module > identified some failures and unimplemented features. > > With this patch set we get: > > test_bpf: Summary: 305 PASSED, 0 FAILED, [85/297 JIT'ed] > > Both big and little endian tested. > > We still lack eBPF support, but this is better than nothing. > > David Daney (5): > MIPS: uasm: Add support for LHU. > MIPS: BPF: Add JIT support for SKF_AD_HATYPE. > MIPS: BPF: Use unsigned access for unsigned SKB fields. > MIPS: BPF: Quit clobbering callee saved registers in JIT code. > MIPS: BPF: Fix multiple problems in JIT skb access helpers. Thanks. Nice set of fixes. Especially patch 4. Did you see crashes because of it? Acked-by: Alexei Starovoitov
Re: Infinite loop when connecting to unreachable NFS servers
On Tue, 2017-03-14 at 23:15 +0100, Sebastian Schmidt wrote:
> Hi,
>
> I was debugging some mysterious high CPU usage and tracked it down to
> monitoring daemon regularly calling stat*() on an NFS automount
> directory. The problem is triggered when mount.nfs passes mount() an
> addr= that points to an unreachable address (i.e. connecting fails
> immediately).
>
> One way to reproduce is by trying to mount Google's DNS server, whose
> IPv6 address isn't properly parsed or rejected by nfs-utils, causing an
> invalid addr= to be passed to mount():
>
> # strace -vf mount.nfs -v 2001:4860:4860:0:0:0:0::/ /mnt
> write(1, "mount.nfs: timeout set for Tue Mar 14 22:57:49 2017", ...
> [...]
> socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
> bind(3, {sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> connect(3, {sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("0.0.7.209")}, 16) = -1 EINVAL (Invalid argument)
> close(3)= 0
> write(1, "mount.nfs: trying text-based options
> 'vers=4.2,addr=0.0.7.209,clientaddr=0.0.0.0'", ...
> mount("2001:4860:4860:0:0:0:0::/", "/mnt", "nfs", 0,
> "vers=4.2,addr=0.0.7.209,clientad"...) = ?
> +++ killed by SIGKILL +++
>
That mount syntax is invalid. From nfs(5):
The server's hostname can be an unqualified hostname, a fully qualified
domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in
square brackets. Link-local and site-local IPv6 addresses must be
accompanied by an interface identifier. See ipv6(7) for details on
specifying raw IPv6 addresses.
So, something like this may work better:
mount -t nfs '[2001:4860:4860:0:0:0:0:]:/' /mnt
> While this is certainly a bug in mount.nfs, too, the bug can also be
> triggered with net.conf.ipv6.all.disable_ipv6=1 and using a hostname that
> resolves to an IPv6 address only (/etc/hosts works) with mount.nfs.
>
> <4>[ 6564.082853] RPC: 8 sleep_on(queue "xprt_pending" time 4296533344)
> <4>[ 6564.082855] RPC: 8 added to queue 8a673b146a18 "xprt_pending"
> <4>[ 6564.082858] RPC: 8 setting alarm for 18 ms
> <4>[ 6564.082860] RPC: xs_connect scheduled xprt 8a673b146800
> <4>[ 6564.082863] RPC: 8 sync task going to sleep
> <4>[ 6564.082868] RPC: xs_bind
> ::::::::784: ok (0)
> <4>[ 6564.082870] RPC: worker connecting xprt 8a673b146800 via tcp
> to 2001:4860:4860:: (port 2049)
> <4>[ 6564.082874] RPC: 8a673b146800 connect status 99 connected 0
> sock state 7
> <4>[ 6564.082876] RPC: 8 __rpc_wake_up_task (now 4296533344)
> <4>[ 6564.082878] RPC: 8 disabling timer
> <4>[ 6564.082880] RPC: 8 removed from queue 8a673b146a18
> "xprt_pending"
> <4>[ 6564.082883] RPC: __rpc_wake_up_task done
> <4>[ 6564.082885] RPC: xs_tcp_state_change client 8a673b146800...
> <4>[ 6564.082887] RPC: state 7 conn 0 dead 0 zapped 1 sk_shutdown 3
> <4>[ 6564.082889] RPC: disconnected transport 8a673b146800
> <4>[ 6564.082893] RPC: wake_up_first(8a673b146970 "xprt_sending")
> <4>[ 6564.082897] RPC: 8 sync task resuming
> <4>[ 6564.082899] RPC: 8 xprt_connect_status: retrying
> <4>[ 6564.082901] RPC: 8 call_connect_status (status -11)
> <4>[ 6564.082903] RPC: 8 call_timeout (minor)
> <4>[ 6564.082905] RPC: 8 call_bind (status 0)
> <4>[ 6564.082907] RPC: 8 call_connect xprt 8a673b146800 is not
> connected
> <4>[ 6564.082909] RPC: 8 xprt_connect xprt 8a673b146800 is not
> connected
> <4>[ 6564.082912] RPC: 8 sleep_on(queue "xprt_pending" time 4296533344)
> <4>[ 6564.082913] RPC: 8 added to queue 8a673b146a18 "xprt_pending"
> <4>[ 6564.082914] RPC: 8 setting alarm for 18 ms
> <4>[ 6564.082914] RPC: xs_connect scheduled xprt 8a673b146800
> <4>[ 6564.082916] RPC: 8 sync task going to sleep
> <4>[ 6564.082919] RPC: xs_bind
> ::::::::938: ok (0)
> <4>[ 6564.082920] RPC: worker connecting xprt 8a673b146800 via tcp
> to 2001:4860:4860:: (port 2049)
> <4>[ 6564.082923] RPC: 8a673b146800 connect status 99 connected 0
> sock state 7
> <4>[ 6564.082924] RPC: 8 __rpc_wake_up_task (now 4296533344)
> <4>[ 6564.082924] RPC: 8 disabling timer
> (and so on, until mount() times out)
>
> Similar for the IPv6-literal test case, where it's failing to connect to
> 0.0.7.209, so it's affecting IPv4, too. While grepping around I found a
> comment saying "If a UDP socket connect fails, the delay behavior here
> prevents retry floods (hard mounts)." for xs_connect(), but I haven't
> figured out how to trigger the UDP connection code.
>
--
Jeff Layton
Re: [PATCH v2 0/5] MIPS: BPF: JIT fixes and improvements.
On 03/14/2017 03:49 PM, Alexei Starovoitov wrote: On Tue, Mar 14, 2017 at 02:21:39PM -0700, David Daney wrote: Changes from v1: - Use unsigned access for SKF_AD_HATYPE - Added three more patches for other problems found. Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module identified some failures and unimplemented features. With this patch set we get: test_bpf: Summary: 305 PASSED, 0 FAILED, [85/297 JIT'ed] Both big and little endian tested. We still lack eBPF support, but this is better than nothing. David Daney (5): MIPS: uasm: Add support for LHU. MIPS: BPF: Add JIT support for SKF_AD_HATYPE. MIPS: BPF: Use unsigned access for unsigned SKB fields. MIPS: BPF: Quit clobbering callee saved registers in JIT code. MIPS: BPF: Fix multiple problems in JIT skb access helpers. Thanks. Nice set of fixes. Especially patch 4. Did you see crashes because of it? Only when running the test-bpf module. The "JMP_JA: Jump, gap, jump, ..." test doesn't actually use any registers, which I think is somewhat uncommon in BPF code. The system would either crash or have weird behavior after running this test. Acked-by: Alexei Starovoitov
