Re: [PATCH v2 0/9] ARM: dts: Add compatible property to "partitions" node
Hi,
On Mon, Dec 21, 2015 at 11:33:44AM +0100, Geert Uytterhoeven wrote:
> Hi,
>
> As of commit e488ca9f8d4f62c2 ("doc: dt: mtd: partitions: add compatible
> property to "partitions" node"), which is in v4.4-rc6, the "partitions"
> subnode of an SPI FLASH device node must have a compatible property. The
> partitions are no longer detected if it is not present.
>
> However, several DTSes in -next have already been converted to the
> "partitions" subnode without "compatible" property, introduced by
> commits 5cfdedb7b9a0fe38 ("mtd: ofpart: move ofpart partitions to a
> dedicated dt node") and fe2585e9c29a650a ("doc: dt: mtd: support
> partitions in a special 'partitions' subnode"). Hence all of these are
> now broken in -next, and will be broken in upstream during the merge
> window.
So, if I understand this correctly, the partitions format was added for v4.4,
then this non-backwards compatible change was added in -rc6. But, there were
also DT files that had the new-for-v4.4 partitions nodes in them that then
stopped working in -rc6?
That sounds like a regression, so this should be picked up as fixes for v4.4.
Please confirm that I've understood the setup correctly, and I'll apply the
series directly to fixes.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] um: Fix pointer cast
Am 22.12.2015 um 21:44 schrieb Mickaël Salaün:
> Fix a pointer cast typo introduced in v4.4-rc5 especially visible for
> the i386 subarchitecture where it results in a kernel crash.
>
> Fixes: 8090bfd2bb9a ("um: Fix fpstate handling")
>
> Signed-off-by: Mickaël Salaün
> Cc: Jeff Dike
> Cc: Richard Weinberger
> Cc: Linus Torvalds
> ---
> arch/x86/um/signal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/um/signal.c b/arch/x86/um/signal.c
> index e5f854ce2d72..cbb541b80358 100644
> --- a/arch/x86/um/signal.c
> +++ b/arch/x86/um/signal.c
> @@ -470,7 +470,7 @@ long sys_sigreturn(void)
> struct sigcontext __user *sc = >sc;
> int sig_size = (_NSIG_WORDS - 1) * sizeof(unsigned long);
>
> - if (copy_from_user([0], (void *)sc->oldmask,
> sizeof(set.sig[0])) ||
> + if (copy_from_user([0], (void *)>oldmask,
> sizeof(set.sig[0])) ||
> copy_from_user([1], frame->extramask, sig_size))
> goto segfault;
o_O, thanks for catching this!
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/2] um: Use race-free temporary file creation
Open the memory mapped file with the O_TMPFILE flag when available. Signed-off-by: Mickaël Salaün Cc: Jeff Dike Cc: Richard Weinberger Acked-by: Tristan Schmelcher --- arch/um/os-Linux/mem.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/um/os-Linux/mem.c b/arch/um/os-Linux/mem.c index 840d573f7e38..8b1767668515 100644 --- a/arch/um/os-Linux/mem.c +++ b/arch/um/os-Linux/mem.c @@ -106,6 +106,17 @@ static int __init make_tempfile(const char *template) } } +#ifdef O_TMPFILE + fd = open(tempdir, O_CLOEXEC | O_RDWR | O_EXCL | O_TMPFILE, 0700); + /* +* If the running system does not support O_TMPFILE flag then retry +* without it. +*/ + if (fd != -1 || (errno != EINVAL && errno != EISDIR && + errno != EOPNOTSUPP)) + return fd; +#endif + tempname = malloc(strlen(tempdir) + strlen(template) + 1); if (tempname == NULL) return -1; -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] ARM: mvebu: ix4-300d: Add compatible property to "partitions" node
On Mon, Dec 21, 2015 at 05:48:48PM +0100, Gregory CLEMENT wrote:
> Hi Geert,
>
> On lun., d??c. 21 2015, Geert Uytterhoeven wrote:
>
> > As of commit e488ca9f8d4f62c2 ("doc: dt: mtd: partitions: add compatible
> > property to "partitions" node"), the "partitions" subnode of an SPI
> > FLASH device node must have a compatible property. The partitions are no
> > longer detected if it is not present.
> >
> > Signed-off-by: Geert Uytterhoeven
> > Acked-by: Brian Norris
>
> Applied on mvebu/dt (with the hope that it is still time to push it to
> arm-soc)
I think we should just take this directly, so feel free to drop it. I'll
followup on 0/9.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] posix-clock: fix return code on the poll method's error path
The posix_clock_poll function is supposed to return a bit mask of
POLLxxx values. However, in case the hardware has disappeared (due to
hot plugging for example) this code returns -ENODEV in a futile
attempt to throw an error at the file descriptor level. The kernel's
file_operations interface does not accept such error codes from the
poll method. Instead, this function aught to return POLLERR.
The value -ENODEV does, in fact, contain the POLLERR bit (and almost
all the other POLLxxx bits as well), but only by chance. This patch
fixes code to return a proper bit mask.
Credit goes to Markus Elfring for pointing out the suspicious
signed/unsigned mismatch.
Signed-off-by: Richard Cochran
---
kernel/time/posix-clock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c
index ce033c7..9cff0ab 100644
--- a/kernel/time/posix-clock.c
+++ b/kernel/time/posix-clock.c
@@ -69,10 +69,10 @@ static ssize_t posix_clock_read(struct file *fp, char
__user *buf,
static unsigned int posix_clock_poll(struct file *fp, poll_table *wait)
{
struct posix_clock *clk = get_posix_clock(fp);
- int result = 0;
+ unsigned int result = 0;
if (!clk)
- return -ENODEV;
+ return POLLERR;
if (clk->ops.poll)
result = clk->ops.poll(clk, fp, wait);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kexec: Move some memembers and definitions within the scope of CONFIG_KEXEC_FILE
On Tue, 22 Dec 2015 19:40:39 +0800 Xunlei Pang wrote: > > Following functions will be used only in kexec_file. Please wrap them in > > CONFIG_KEXEC_FILE. > > > > int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf, > > unsigned long buf_len); > > void * __weak arch_kexec_kernel_image_load(struct kimage *image); > > int __weak arch_kimage_file_post_load_cleanup(struct kimage *image); > > int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, > > unsigned long buf_len); > > int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr, > > Elf_Shdr *sechdrs, unsigned int relsec); > > int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr > > *sechdrs, > > unsigned int relsec); > > Thanks for the comment. > > I noticed this as well, but seems for the function declarations we don't need > do this, > since they don't consume the actual space. > > For example, in the include/linux/timekeeping.h > /* > * RTC specific > */ > extern bool timekeeping_rtc_skipsuspend(void); > extern bool timekeeping_rtc_skipresume(void); > > extern void timekeeping_inject_sleeptime64(struct timespec64 *delta); > > also not embraced by the corresponding macros. Yes. If we add the ifdefs then a programming error will be detected at compile time. If we don't add the ifdefs then that error will be detected at link time. So the ifdefs provide a quite small advantage, while making the code harder to read and harder to maintain. I believe that "no ifdefs" is the better side of this tradeoff. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PCI: generic: Refactor code to enable reuse by other drivers.
On Tuesday 22 December 2015, David Daney wrote: > On 12/22/2015 02:07 AM, Will Deacon wrote: > > On Mon, Dec 21, 2015 at 05:53:41PM -0800, David Daney wrote: > >> From: David Daney > >> diff --git a/drivers/pci/host/pci-host-generic.c > >> b/drivers/pci/host/pci-host-generic.c > >> index 5434c90..e83cec7 100644 > >> --- a/drivers/pci/host/pci-host-generic.c > >> +++ b/drivers/pci/host/pci-host-generic.c > [...] > >> -static int gen_pci_probe(struct platform_device *pdev) > >> +int gen_pci_common_probe(struct platform_device *pdev, > >> + struct gen_pci *pci) > > > > Whilst I'm fine with this patch, I don't know how Bjorn will feel about > > exposing this function outside of the generic host driver. We could avoid > > it by turning things upside-down and having the generic driver probe > > the other drivers by matching a compatible string with a probe function > > pointer, but I'd be interested to see what others think. > > > > Note: I know that pci-host-generic is not built as a loadable module, but... > > struct of_device_id, MODULE_DEVICE_TABLE, struct platform_driver and the > registering of platform drivers is fairly well standardized in the > kernel, and module loading userpace tools. Agreed, this is the correct way to do the abstraction if we want one, the way that Will describes is generally not a good idea, and we've converted a number of drivers that did it like that to the way you do it here. > The struct of_device_id, MODULE_DEVICE_TABLE must really reside in the > same module as the driver for the device. We are creating a separate > driver precisely because we don't want to mix all this ThunderX specific > code into the pci-host-generic driver when it is used by arm-32bit and > others. This means that, at a minimum, we would have to export the > pci-host-generic probe function so that it could be referenced by struct > platform_driver in other modules. Right. > This brings up the next problem. How to attach driver specific data to > the generic driver structures? At first I tried augmenting struct > gen_pci_cfg_bus_ops with a callback .init() function to be called by the > generic driver, but this would also require adding an an element to > struct gen_pci to point to a driver specific data object. It felt a > little convoluted and complex. > > This led me to the current design where struct gen_pci is embedded in > the driver specific structure, and the allocation of this is done in the > driver specific probe function. No more callbacks, no additions to the > pci-host-generic structures. I think it is a little cleaner this way. > > If there are suggestions as to how it can be made cleaner yet, I would > be happy to implement and test them. My idea of the long-term direction for the pci-host-generic driver would be to move more parts into the PCI core code as library functions that can be used by other drivers as well. This would also address my other concern that I'd like to see the generic host driver remain the simplest example that we have, and only require any additional code in other drivers to add functionality or workarounds. Adding an abstraction layer within the driver to some degree goes in the opposite direction of that. One approach that might work would be to split the existing driver into three files: one for CAM, one for ECAM and one for the common parts, with an interface similar to what you have here. Then you can add your driver as a third front-end, and we can keep working on integrating the common parts further into the PCI core. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net: user-controllable kmalloc size in __sctp_setsockopt_connectx
Hi, On Tue, Dec 22, 2015 at 09:13:54PM +0100, Dmitry Vyukov wrote: > Hello, ... > > [] __sctp_setsockopt_connectx+0xc6/0x150 > net/sctp/socket.c:1318 > [< inline >] sctp_getsockopt_connectx3 net/sctp/socket.c:1410 > [] sctp_getsockopt+0x25ee/0x3e00 net/sctp/socket.c:6007 > [] sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2601 > [< inline >] SYSC_getsockopt net/socket.c:1782 > [] SyS_getsockopt+0x142/0x230 net/socket.c:1764 > [] entry_SYSCALL_64_fastpath+0x16/0x7a > arch/x86/entry/entry_64.S:185 This is similar to that other one. I'll send a patch for it tomorrow. Thanks, Marcelo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] free_pages stuff
On Tue, Dec 22, 2015 at 09:21:14AM +0100, Geert Uytterhoeven wrote: > On Tue, Dec 22, 2015 at 3:22 AM, Al Viro wrote: > >> And if the code really explicitly wants a page (or set of aligned pages) > >> for some vm reason, I suspect having the cast there isn't a bad thing. It's > >> clearly not just a random pointer allocation if the bit pattern of the > >> pointer matters. > > > > BTW, I'm not sure we don't have code that would assume that > > kmalloc(PAGE_SIZE,...) always returns something PAGE_SIZE-aligned. > > Yeah, needs-to-be-PAGE_SIZE-aligned is probably one of the main > reasons of not calling kmalloc(). FWIW, looking through the fs/* uses of __get_free_pages() and its wrappers... * affs_grow_extcache() - might as well have been kmalloc (and I'm not sure that fixed PAGE_SIZE is the best size there, actually). * afs_mntpt_do_automount() - kmalloc(). * bfs_dump_imap() - kmalloc(). * bm_entry_read() - kmalloc(), and might be better off with single_open-style seqfile. * ceph_alloc_readdir_reply_buffer() - kmalloc(). * configfs fill_write_buffer() - kmalloc(), and it might be worth a helper similar to memdup_user() that would allocate size + 1 bytes, copy size bytes from user and put '\0' after them. There's a lot of ->write() instances open-coding that. * configfs fill_read_buffer() - kmalloc(). * configfs_follow_link() - kmalloc(). * ext4_calculate_overhead() - kmalloc(). * fuse_follow_link() - kmalloc(). * fuse_do_ioctl() - kmalloc(), and it might as well do more accurate size calculation * hfs_mdb_get() - 8Kb kmalloc(). * isofs_readdir() - kmalloc(). * jbd2_alloc() - really wants alignment; might make sense to have 3 more private slabs there (they are using kmem_cache_alloc() for sub-page allocation, with explicit alignments set when creating those; anything from 8 pages and up goes to vmalloc()). * jfs_readdir() - kmalloc(). * jfs lbmLogInit() - alloc_page(). _This_ is one that really wants struct page (and uses virt_to_page() to get it after get_zeroed_page()). * kernfs_iop_follow_link() - kmalloc(). * simple_transaction_get() - kmalloc(). * copy_mount_options() - kmalloc(). * nfs_do_submount() - kmalloc(). * nfs_follow_referral() - kmalloc(). * nfs4_replace_transport() - kmalloc(). * nfs_show_devname() - kmalloc(). * nfsd_buffered_readdir() - kmalloc(). * nilfs_ioctl_wrap_copy() - kmalloc() (and I'm not sure that PAGE_SIZE is the best possible variant there). * fs/ocfs2/dlm/dlmdebug.c ones - kmalloc(), all of them. * dlm_alloc_pagevec() - used to allocate hash tables. kmalloc() will definitely do, but I would consider using a single kmalloc or vmalloc instead of an array of page-sized blocks. Guaranteed extra dereference on every hash lookup is potentially painful. * dlm_migrate_lockres() - kmalloc(). * dlm_request_all_locks_handler() - kmalloc(). * ovl_read_symlink() - kmalloc(). * do_proc_readlink() - kmalloc(). * proc_pid_cmdline_read() - kmalloc(). * proc_pid_attr_write() - memdup_user(). * mem_rw() - kmalloc(). * environ_read() - kmalloc(). * dquot_init() - hash allocation; alloc_large_system_hash(), unless there's something I'm missing... * poll_get_entry() - kmalloc(), probably. * fs/proc/vmcore.c - interesting one; it allocates a buffer to store elf headers from crashdump, and everything would be simple, expect for mmap() support in there. Which wants it to be page-aligned and uses remap_pfn_range() from that sucker. IOW, there is one place that can't live with kmalloc() due to alignment requirements (jbd2_alloc()), one place that wants struct page * (in jfs) and one place that wants page-aligned buffer it will feed to remap_pfn_range(). And 35 places that have no good reason for using __get_free_pages() or its wrappers. So at least for fs/* the answer is definitely "almost all places where we are using page allocator would be better off with something else". Documentation/which-allocator-should-I-use might be a good idea... Notes below are just a skeleton - a lot of details need to be added; in particular, there should be a part on "I have this kind of address and I want that; when and how should that be done?", completely missing here. And there should be a big scary warning along the lines of "this is NOT an invitation for a flood of checkpatch-inspired patches"... Comments, corrections and additions would be very welcome. 1) Most of the time kmalloc() is the right thing to use. Limitations: alignment is no better than word, not available very early in bootstrap, allocated memory is physically contiguous, so large allocations are best avoided. 2) kmem_cache_alloc() allows to specify the alignment at cache creation time. Otherwise it's similar to kmalloc(). Normally it's
Re: [PATCH] asus-wmi: drop to_platform_driver macro
On Tue, Dec 22, 2015 at 10:16:13PM +0800, Geliang Tang wrote: > to_platform_driver has been defined in platform_device.h, so drop > this repetitive macro in asus-wmi.c. > > Signed-off-by: Geliang Tang Thanks, applied. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipv6/addrlabel: fix ip6addrlbl_get()
From: Andrey Ryabinin
Date: Mon, 21 Dec 2015 12:54:45 +0300
> ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded,
> ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed,
> ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer.
>
> Fix this by inverting ip6addrlbl_hold() check.
>
> Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address
> selection policy table.")
> Signed-off-by: Andrey Ryabinin
Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided
Hi Mika,
On 12/18/2015 4:13 AM, Mika Westerberg wrote:
[]
So instead of this, what if we do not assign dev->get_clk_rate_khz at
all and then do something like below in the core driver?
I like the changes below since it is clear to see within the core file
how things are handled when get_clk_rate_khz is not assigned (i.e.
input_clock_hz = 0), and not necessary relying on the platform driver to
return 0 in this case.
So, at this point, I can re-submit the V3 and combine these changes, and
we both can sign-off. How does that sound?
Thanks,
Suravee
Of course we still need the other changes you did in this patch to cope
with the missing clock.
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 8c48b27ba059..25dccd8df772 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -271,6 +271,17 @@ static void __i2c_dw_enable(struct dw_i2c_dev *dev, bool
enable)
enable ? "en" : "dis");
}
+static unsigned long i2c_dw_clk_rate(struct dw_i2c_dev *dev)
+{
+ /*
+* Clock is not necessary if we got LCNT/HCNT values directly from
+* the platform code.
+*/
+ if (WARN_ON_ONCE(!dev->get_clk_rate_khz))
+ return 0;
+ return dev->get_clk_rate_khz(dev);
+}
+
/**
* i2c_dw_init() - initialize the designware i2c master hardware
* @dev: device private data
@@ -281,7 +292,6 @@ static void __i2c_dw_enable(struct dw_i2c_dev *dev, bool
enable)
*/
int i2c_dw_init(struct dw_i2c_dev *dev)
{
- u32 input_clock_khz;
u32 hcnt, lcnt;
u32 reg;
u32 sda_falling_time, scl_falling_time;
@@ -295,8 +305,6 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
}
}
- input_clock_khz = dev->get_clk_rate_khz(dev);
-
reg = dw_readl(dev, DW_IC_COMP_TYPE);
if (reg == ___constant_swab32(DW_IC_COMP_TYPE_VALUE)) {
/* Configure register endianess access */
@@ -325,12 +333,12 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
hcnt = dev->ss_hcnt;
lcnt = dev->ss_lcnt;
} else {
- hcnt = i2c_dw_scl_hcnt(input_clock_khz,
+ hcnt = i2c_dw_scl_hcnt(i2c_dw_clk_rate(dev),
4000, /* tHD;STA = tHIGH = 4.0 us */
sda_falling_time,
0, /* 0: DW default, 1: Ideal */
0); /* No offset */
- lcnt = i2c_dw_scl_lcnt(input_clock_khz,
+ lcnt = i2c_dw_scl_lcnt(i2c_dw_clk_rate(dev),
4700, /* tLOW = 4.7 us */
scl_falling_time,
0); /* No offset */
@@ -344,12 +352,12 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
hcnt = dev->fs_hcnt;
lcnt = dev->fs_lcnt;
} else {
- hcnt = i2c_dw_scl_hcnt(input_clock_khz,
+ hcnt = i2c_dw_scl_hcnt(i2c_dw_clk_rate(dev),
600,/* tHD;STA = tHIGH = 0.6 us */
sda_falling_time,
0, /* 0: DW default, 1: Ideal */
0); /* No offset */
- lcnt = i2c_dw_scl_lcnt(input_clock_khz,
+ lcnt = i2c_dw_scl_lcnt(i2c_dw_clk_rate(dev),
1300, /* tLOW = 1.3 us */
scl_falling_time,
0); /* No offset */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/7] mm/slab_common.c: Add common support for slab saniziation
On 22.12.2015 4:40, Laura Abbott wrote:
> Each of the different allocators (SLAB/SLUB/SLOB) handles
> clearing of objects differently depending on configuration.
> Add common infrastructure for selecting sanitization levels
> (off, slow path only, partial, full) and marking caches as
> appropriate.
>
> All credit for the original work should be given to Brad Spengler and
> the PaX Team.
>
> Signed-off-by: Laura Abbott
>
> +#ifdef CONFIG_SLAB_MEMORY_SANITIZE
> +#ifdef CONFIG_X86_64
> +#define SLAB_MEMORY_SANITIZE_VALUE '\xfe'
> +#else
> +#define SLAB_MEMORY_SANITIZE_VALUE '\xff'
> +#endif
> +enum slab_sanitize_mode {
> + /* No sanitization */
> + SLAB_SANITIZE_OFF = 0,
> +
> + /* Partial sanitization happens only on the slow path */
> + SLAB_SANITIZE_PARTIAL_SLOWPATH = 1,
Can you explain more about this variant? I wonder who might find it useful
except someone getting a false sense of security, but cheaper.
It sounds like wanting the cake and eat it too :)
I would be surprised if such IMHO half-solution existed in the original
PAX_MEMORY_SANITIZE too?
Or is there something that guarantees that the objects freed on hotpath won't
stay there for long so the danger of leak is low? (And what about
use-after-free?) It depends on further slab activity, no? (I'm not that familiar
with SLUB, but I would expect the hotpath there being similar to SLAB freeing
the object on per-cpu array_cache. But, it seems the PARTIAL_SLOWPATH is not
implemented for SLAB, so there might be some fundamental difference I'm
missing.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] clk: samsung: exynos5422: add missing parent GSCL block clocks
On 12/22, Sylwester Nawrocki wrote: > Mike, > > On 22/12/15 19:44, Mike Turquette wrote: > > This is superseded by the pull request found in Message-ID: > > <5671a456.9030...@samsung.com>, correct? > > The two pull requests are based on same branch, first 2 commits are > tagged with for-4.5-clk-exynos5420 tag and the whole branch is tagged > as clk-samsung-4.5. I assumed it's fine to use just the below tag for > arm-soc. OK, I'll interpret that as a "yes". Thanks, Mike > > >>> > > The following changes since commit > >>> > > 9f9499ae8e6415cefc4fe0a96ad0e27864353c89: > >>> > > > >>> > > Linux 4.4-rc5 (2015-12-13 17:42:58 -0800) > >>> > > > >>> > > are available in the git repository at: > >>> > > > >>> > > git://linuxtv.org/snawrocki/samsung.git tags/for-4.5-clk-exynos5420 > >>> > > > >>> > > for you to fetch changes up to > >>> > > bee4f87f01dc30fcf9e05eb55b833f89fd9bb4f4: > >>> > > > >>> > > clk: samsung: exynos5420: add cpu clock configuration data and > >>> > > instantiate cpu clock (2015-12-16 16:35:26 +0100) > >>> > > > >>> > > > >>> > > Samsung exynos5420 SoC clk subsystem support updates: > >>> > > instantiation of the cpu clocks and addition of the GSCL > >>> > > IP parent clocks to the list of available consumer clocks. > >>> > > > >>> > > > >>> > > Marek Szyprowski (1): > >>> > > clk: samsung: exynos542x: add missing parent GSCL block clocks > >>> > > > >>> > > Thomas Abraham (1): > >>> > > clk: samsung: exynos5420: add cpu clock configuration data and > >>> > > instantiate cpu clock > >>> > > > >>> > > drivers/clk/samsung/clk-exynos5420.c | 66 > >>> > > +--- > >>> > > include/dt-bindings/clock/exynos5420.h |4 ++ > >>> > > 2 files changed, 64 insertions(+), 6 deletions(-) > > -- > Regards, > Sylwester > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [OOPS] BUG_ON in cgroups on 4.4.0-rc5-next
> Hello, Alex. > > On Fri, Dec 18, 2015 at 08:08:03PM +, Alex Ng (LIS) wrote: > > Hi, > > > > I was running a "git clone" of the linux-next source tree and hit the > following BUG_ON condition. My box is running kernel 4.4.0-rc5-next- > 20151217-52.27. Any ideas on how to pin down the cause? > > > > The trace indicates that the following condition in compare_css_sets() > triggered the oops: > > Can you please let me know the steps to reproduce the bug? I tried this on a Hyper-V VM hosted in Windows Server 2012R2 and ran the attached script. The script clones the linux-next tree in a random directory under /tmp in a tight loop. This panic is not always reproducible, and I have only hit it once after running the script about 10 times. A different kernel panic happens each time I run this script; and the panics always happen during the first iteration of the loop. Let me know if you need more information. Hope this helps, Alex test.sh Description: test.sh
Re: [PATCH] [media] rc: sunxi-cir: Initialize the spinlock properly
Hi,
On Tue, Dec 22, 2015 at 12:27:35PM +0800, Chen-Yu Tsai wrote:
> The driver allocates the spinlock but fails to initialize it correctly.
> The kernel reports a BUG indicating bad spinlock magic when spinlock
> debugging is enabled.
>
> Call spin_lock_init() on it to initialize it correctly.
>
> Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver")
> Signed-off-by: Chen-Yu Tsai
You should probably Cc stable on this one.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH] dccp: fix use-after-free after cloning struct dccp_sock
From: Vegard Nossum Date: Sun, 20 Dec 2015 21:53:27 +0100 > @@ -115,6 +115,10 @@ struct sock *dccp_create_openreq_child(const struct sock > *sk, > newdp->dccps_isr = dreq->dreq_isr; > newdp->dccps_gsr = dreq->dreq_gsr; > > + newdp->dccps_hc_rx_ackvec = NULL; > + newdp->dccps_hc_rx_ccid = NULL; > + newdp->dccps_hc_tx_ccid = NULL; ->dccps_hc_rx_ackvec is set to NULL several lines above this, so you don't need to add that case here. WRT the ccid pointers, I don't think we can just NULL them out. If the parent socket has these CCID features enabled, we have to clone them into the child somehow. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
Hi Stefano,
[auto build test WARNING on arm/for-next]
[also build test WARNING on v4.4-rc6 next-20151222]
url:
https://github.com/0day-ci/linux/commits/Stefano-Stabellini/arm-remove-CPU_V6-and-GENERIC_ATOMIC64-build-dependencies-for-XEN/20151222-222129
base: http://repo.or.cz/linux-2.6/linux-2.6-arm.git for-next
config: arm-allmodconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
drivers/gpu/drm/exynos/exynos_drm_ipp.c: In function 'ipp_get_mem_node':
>> drivers/gpu/drm/exynos/exynos_drm_ipp.c:585:4: warning: format '%x' expects
>> argument of type 'unsigned int', but argument 4 has type 'dma_addr_t'
>> [-Wformat=]
DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%lx]\n", i,
^
--
In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/clk.h:16,
from drivers/gpu/drm/sti/sti_hqvdp.c:7:
drivers/gpu/drm/sti/sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
>> drivers/gpu/drm/sti/sti_hqvdp.c:605:3: note: in expansion of macro 'dev_dbg'
dev_dbg(hqvdp->dev, "%s Posted command:0x%x\n",
^
drivers/gpu/drm/sti/sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/gpu/drm/sti/sti_hqvdp.c:931:2: note: in expansion of macro 'dev_dbg'
dev_dbg(hqvdp->dev, "%s Posted command:0x%x\n",
^
--
In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/media/platform/soc_camera/mx3_camera.c:13:
drivers/media/platform/soc_camera/mx3_camera.c: In function
'mx3_cam_dma_done':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
>> drivers/media/platform/soc_camera/mx3_camera.c:149:2: note: in expansion of
>> macro 'dev_dbg'
dev_dbg(chan->device->dev, "callback cookie %d, active DMA 0x%08x\n",
^
drivers/media/platform/soc_camera/mx3_camera.c: In function
'mx3_videobuf_queue':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/media/platform/soc_camera/mx3_camera.c:341:2: note: in expansion of
macro 'dev_dbg'
dev_dbg(icd->parent, "Submitted cookie %d DMA 0x%08x\n",
^
drivers/media/platform/soc_camera/mx3_camera.c: In function
'mx3_videobuf_release':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBU
Re: [PATCH v2 3/3] scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
On 15-11-24 04:42 AM, Rasmus Villemoes wrote:
On 64 bit, struct error_info has 6 bytes of padding, which amounts to
over 4k of wasted space in the additional[] array. We could easily get
rid of that by instead using separate arrays for the codes and the
pointers. However, we can do even better than that and save an
additional 6 bytes per entry: In the table, just store the sizeof()
the corresponding string literal. The cumulative sum of these is then
the appropriate offset into additional_text, which is built from the
concatenation (with '\0's inbetween) of the strings.
$ scripts/bloat-o-meter /tmp/vmlinux vmlinux
add/remove: 0/0 grow/shrink: 1/1 up/down: 24/-8488 (-8464)
function old new delta
scsi_extd_sense_format 136 160 +24
additional 113122824 -8488
Signed-off-by: Rasmus Villemoes
Tested-by: Douglas Gilbert
---
drivers/scsi/constants.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 6e813eec4f8d..83458f7a2824 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -292,17 +292,30 @@ bool scsi_opcode_sa_name(int opcode, int service_action,
struct error_info {
unsigned short code12; /* 0x0302 looks better than 0x03,0x02 */
- const char * text;
+ unsigned short size;
};
+/*
+ * There are 700+ entries in this table. To save space, we don't store
+ * (code, pointer) pairs, which would make sizeof(struct
+ * error_info)==16 on 64 bits. Rather, the second element just stores
+ * the size (including \0) of the corresponding string, and we use the
+ * sum of these to get the appropriate offset into additional_text
+ * defined below. This approach saves 12 bytes per entry.
+ */
static const struct error_info additional[] =
{
-#define SENSE_CODE(c, s) {c, s},
+#define SENSE_CODE(c, s) {c, sizeof(s)},
#include "sense_codes.h"
#undef SENSE_CODE
- {0, NULL}
};
+static const char *additional_text =
+#define SENSE_CODE(c, s) s "\0"
+#include "sense_codes.h"
+#undef SENSE_CODE
+ ;
+
struct error_info2 {
unsigned char code1, code2_min, code2_max;
const char * str;
@@ -364,11 +377,14 @@ scsi_extd_sense_format(unsigned char asc, unsigned char
ascq, const char **fmt)
{
int i;
unsigned short code = ((asc << 8) | ascq);
+ unsigned offset = 0;
*fmt = NULL;
- for (i = 0; additional[i].text; i++)
+ for (i = 0; i < ARRAY_SIZE(additional); i++) {
if (additional[i].code12 == code)
- return additional[i].text;
+ return additional_text + offset;
+ offset += additional[i].size;
+ }
for (i = 0; additional2[i].fmt; i++) {
if (additional2[i].code1 == asc &&
ascq >= additional2[i].code2_min &&
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] scsi: make some Additional Sense strings more grep'able
On 15-11-24 04:42 AM, Rasmus Villemoes wrote:
There's little point in breaking these strings over multiple lines.
Signed-off-by: Rasmus Villemoes
Tested-by: Douglas Gilbert
---
drivers/scsi/constants.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index fa09d4be2b53..58d94e3c3713 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -346,11 +346,9 @@ static const struct error_info additional[] =
{0x0407, "Logical unit not ready, operation in progress"},
{0x0408, "Logical unit not ready, long write in progress"},
{0x0409, "Logical unit not ready, self-test in progress"},
- {0x040A, "Logical unit not accessible, asymmetric access state "
-"transition"},
+ {0x040A, "Logical unit not accessible, asymmetric access state
transition"},
{0x040B, "Logical unit not accessible, target port in standby state"},
- {0x040C, "Logical unit not accessible, target port in unavailable "
-"state"},
+ {0x040C, "Logical unit not accessible, target port in unavailable
state"},
{0x040D, "Logical unit not ready, structure check required"},
{0x040E, "Logical unit not ready, security session in progress"},
{0x0410, "Logical unit not ready, auxiliary memory not accessible"},
@@ -363,11 +361,9 @@ static const struct error_info additional[] =
{0x0417, "Logical unit not ready, calibration required"},
{0x0418, "Logical unit not ready, a door is open"},
{0x0419, "Logical unit not ready, operating in sequential mode"},
- {0x041A, "Logical unit not ready, start stop unit command in "
-"progress"},
+ {0x041A, "Logical unit not ready, start stop unit command in progress"},
{0x041B, "Logical unit not ready, sanitize in progress"},
- {0x041C, "Logical unit not ready, additional power use not yet "
-"granted"},
+ {0x041C, "Logical unit not ready, additional power use not yet
granted"},
{0x041D, "Logical unit not ready, configuration in progress"},
{0x041E, "Logical unit not ready, microcode activation required"},
{0x041F, "Logical unit not ready, microcode download required"},
@@ -559,8 +555,7 @@ static const struct error_info additional[] =
{0x2300, "Invalid token operation, cause not reportable"},
{0x2301, "Invalid token operation, unsupported token type"},
{0x2302, "Invalid token operation, remote token usage not supported"},
- {0x2303, "Invalid token operation, remote rod token creation not "
-"supported"},
+ {0x2303, "Invalid token operation, remote rod token creation not
supported"},
{0x2304, "Invalid token operation, token unknown"},
{0x2305, "Invalid token operation, token corrupt"},
{0x2306, "Invalid token operation, token revoked"},
@@ -641,8 +636,7 @@ static const struct error_info additional[] =
{0x2A0D, "Data encryption capabilities changed"},
{0x2A10, "Timestamp changed"},
{0x2A11, "Data encryption parameters changed by another i_t nexus"},
- {0x2A12, "Data encryption parameters changed by vendor specific "
-"event"},
+ {0x2A12, "Data encryption parameters changed by vendor specific event"},
{0x2A13, "Data encryption key instance counter has changed"},
{0x2A14, "SA creation capabilities data has changed"},
{0x2A15, "Medium removal prevention preempted"},
@@ -759,8 +753,7 @@ static const struct error_info additional[] =
{0x3B19, "Element enabled"},
{0x3B1A, "Data transfer device removed"},
{0x3B1B, "Data transfer device inserted"},
- {0x3B1C, "Too many logical objects on partition to support "
-"operation"},
+ {0x3B1C, "Too many logical objects on partition to support operation"},
{0x3D00, "Invalid bits in identify message"},
@@ -957,8 +950,7 @@ static const struct error_info additional[] =
{0x5D39, "Data channel impending failure throughput performance"},
{0x5D3A, "Data channel impending failure seek time performance"},
{0x5D3B, "Data channel impending failure spin-up retry count"},
- {0x5D3C, "Data channel impending failure drive calibration retry "
-"count"},
+ {0x5D3C, "Data channel impending failure drive calibration retry
count"},
{0x5D40, "Servo impending failure general hard drive failure"},
{0x5D41, "Servo impending failure drive error rate too high"},
{0x5D42, "Servo impending failure data error rate too high"},
@@ -1070,8 +1062,7 @@ static const struct error_info additional[] =
{0x6E00, "Command to logical unit failed"},
- {0x6F00, "Copy protection key exchange failure - authentication "
-"failure"},
+ {0x6F00, "Copy protection key exchange failure - authentication
failure"},
{0x6F01, "Copy
Re: [PATCH v2 2/3] scsi: move Additional Sense Codes to separate file
On 15-11-24 04:42 AM, Rasmus Villemoes wrote:
This is a purely mechanical move of the list of additional sense codes
to a separate file, in preparation for reducing the impact of choosing
CONFIG_SCSI_CONSTANTS=y by about 8k.
Signed-off-by: Rasmus Villemoes
Tested-by: Douglas Gilbert
---
drivers/scsi/constants.c | 830 +
drivers/scsi/sense_codes.h | 826
2 files changed, 829 insertions(+), 827 deletions(-)
create mode 100644 drivers/scsi/sense_codes.h
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 58d94e3c3713..6e813eec4f8d 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -295,835 +295,11 @@ struct error_info {
const char * text;
};
-/*
- * The canonical list of T10 Additional Sense Codes is available at:
- * http://www.t10.org/lists/asc-num.txt [most recent: 20141221]
- */
-
static const struct error_info additional[] =
{
- {0x, "No additional sense information"},
- {0x0001, "Filemark detected"},
- {0x0002, "End-of-partition/medium detected"},
- {0x0003, "Setmark detected"},
- {0x0004, "Beginning-of-partition/medium detected"},
- {0x0005, "End-of-data detected"},
- {0x0006, "I/O process terminated"},
- {0x0007, "Programmable early warning detected"},
- {0x0011, "Audio play operation in progress"},
- {0x0012, "Audio play operation paused"},
- {0x0013, "Audio play operation successfully completed"},
- {0x0014, "Audio play operation stopped due to error"},
- {0x0015, "No current audio status to return"},
- {0x0016, "Operation in progress"},
- {0x0017, "Cleaning requested"},
- {0x0018, "Erase operation in progress"},
- {0x0019, "Locate operation in progress"},
- {0x001A, "Rewind operation in progress"},
- {0x001B, "Set capacity operation in progress"},
- {0x001C, "Verify operation in progress"},
- {0x001D, "ATA pass through information available"},
- {0x001E, "Conflicting SA creation request"},
- {0x001F, "Logical unit transitioning to another power condition"},
- {0x0020, "Extended copy information available"},
- {0x0021, "Atomic command aborted due to ACA"},
-
- {0x0100, "No index/sector signal"},
-
- {0x0200, "No seek complete"},
-
- {0x0300, "Peripheral device write fault"},
- {0x0301, "No write current"},
- {0x0302, "Excessive write errors"},
-
- {0x0400, "Logical unit not ready, cause not reportable"},
- {0x0401, "Logical unit is in process of becoming ready"},
- {0x0402, "Logical unit not ready, initializing command required"},
- {0x0403, "Logical unit not ready, manual intervention required"},
- {0x0404, "Logical unit not ready, format in progress"},
- {0x0405, "Logical unit not ready, rebuild in progress"},
- {0x0406, "Logical unit not ready, recalculation in progress"},
- {0x0407, "Logical unit not ready, operation in progress"},
- {0x0408, "Logical unit not ready, long write in progress"},
- {0x0409, "Logical unit not ready, self-test in progress"},
- {0x040A, "Logical unit not accessible, asymmetric access state
transition"},
- {0x040B, "Logical unit not accessible, target port in standby state"},
- {0x040C, "Logical unit not accessible, target port in unavailable
state"},
- {0x040D, "Logical unit not ready, structure check required"},
- {0x040E, "Logical unit not ready, security session in progress"},
- {0x0410, "Logical unit not ready, auxiliary memory not accessible"},
- {0x0411, "Logical unit not ready, notify (enable spinup) required"},
- {0x0412, "Logical unit not ready, offline"},
- {0x0413, "Logical unit not ready, SA creation in progress"},
- {0x0414, "Logical unit not ready, space allocation in progress"},
- {0x0415, "Logical unit not ready, robotics disabled"},
- {0x0416, "Logical unit not ready, configuration required"},
- {0x0417, "Logical unit not ready, calibration required"},
- {0x0418, "Logical unit not ready, a door is open"},
- {0x0419, "Logical unit not ready, operating in sequential mode"},
- {0x041A, "Logical unit not ready, start stop unit command in progress"},
- {0x041B, "Logical unit not ready, sanitize in progress"},
- {0x041C, "Logical unit not ready, additional power use not yet
granted"},
- {0x041D, "Logical unit not ready, configuration in progress"},
- {0x041E, "Logical unit not ready, microcode activation required"},
- {0x041F, "Logical unit not ready, microcode download required"},
- {0x0420, "Logical unit not ready, logical unit reset required"},
- {0x0421, "Logical unit not ready, hard reset required"},
- {0x0422, "Logical unit not ready, power cycle required"},
-
- {0x0500, "Logical unit does not respond
Re: [PATCH v2 0/3] scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
On 15-11-24 04:42 AM, Rasmus Villemoes wrote:
This reduces the impact of choosing by about 8KB.
2dd951ecd511 ("scsi: Conditionally compile in constants.c") updated
the Kconfig help text from 12KB to 75KB. The 12K predated git so was
certainly outdated. But I'm not sure where the 75K comes from; using
size(1) on a defconfig (with/without this config option) vmlinux shows
a difference of about 47K, and 39K after these patches are applied. In
any case, I've left the Kconfig text alone, since I'm not sure I'm
counting the same way the 75K was computed (I'm fairly certain of the
8K delta, however).
Tested with a trivial module calling scsi_extd_sense_format with a few
random known codes and comparing the result to the expected value.
v2: prepend patch to unsplit a few string literals for greppability,
leave the NULL sentinel in the .c file in 2/3 (it's removed in 3/3
either way).
Rasmus Villemoes (3):
scsi: make some Additional Sense strings more grep'able
scsi: move Additional Sense Codes to separate file
scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
I have been asked by Martin to look at this series of patches.
The 75 KB win when CONFIG_SCSI_CONSTANTS ("constants") is not
given, looks like an exaggeration. This from dmesg on my x64
lk 4.3.3 kernel before any changes (constants selected):
Memory: 3708576K/3874608K available (6217K kernel code, 888K rwdata,
2624K rodata, 1164K init, 13736K bss, 166032K reserved ...
With these changes (constants selected):
Memory: 3708592K/3874608K available (6217K kernel code, 880K rwdata,
2616K rodata, 1164K init, 13736K bss, 166016K reserved ...
With these changes (constants not selected):
Memory: 3708628K/3874608K available (6216K kernel code, 884K rwdata,
2580K rodata, 1160K init, 13736K bss, 165980K reserved ...
The significant change is with the rodata. So there is an 8 KB win
with this patch set, constants selected, as Rasmus said. But with this
patch the win for constants deselected shrinks to 36 KB (from 44 KB).
As for the patch, I don't see the sense of putting all the array
elements in a header file since it is only reasonable to include
that header file one or zero times in the kernel. Also that header
file include must be embedded inside an array definition (while
most headers are included at file scope and contain guards against
multiple inclusion). Perhaps that header file may be useful for
user space tools to include?
Anyway, with light testing my kernels above properly reported
SCSI status/sense_data with these patches both with constants
selected/de-selected.
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] RDS: don't pretend to use cpu notifiers
From: Santosh Shilimkar Date: Sat, 19 Dec 2015 12:55:43 -0800 > From: Sebastian Andrzej Siewior > > It looks like an attempt to use CPU notifier here which was never > completed. Nobody tried to wire it up completely since 2k9. So I unwind > this code and get rid of everything not required. Oh look! 19 lines were > removed while code still does the same thing. > > Acked-by: Santosh Shilimkar > Tested-by: Santosh Shilimkar > Signed-off-by: Sebastian Andrzej Siewior Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Vijay Pandurangan
Date: Fri, 18 Dec 2015 14:34:59 -0500
> Packets that arrive from real hardware devices have ip_summed ==
> CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
> CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
> current version of veth will replace CHECKSUM_NONE with
> CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
> a veth device to be delivered to the application. This caused applications
> at Twitter to receive corrupt data when network hardware was corrupting
> packets.
>
> We believe this was added as an optimization to skip computing and
> verifying checksums for communication between containers. However, locally
> generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
> written does nothing for them. As far as we can tell, after removing this
> code, these packets are transmitted from one stack to another unmodified
> (tcpdump shows invalid checksums on both sides, as expected), and they are
> delivered correctly to applications. We didn’t test every possible network
> configuration, but we tried a few common ones such as bridging containers,
> using NAT between the host and a container, and routing from hardware
> devices to containers. We have effectively deployed this in production at
> Twitter (by disabling RX checksum offloading on veth devices).
>
> This code dates back to the first version of the driver, commit
> ("[NET]: Virtual ethernet device driver"), so I
> suspect this bug occurred mostly because the driver API has evolved
> significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix
> packet checksumming") (in December 2010) fixed this for packets that get
> created locally and sent to hardware devices, by not changing
> CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
> in from hardware devices.
>
> Co-authored-by: Evan Jones
> Signed-off-by: Evan Jones
> Cc: Nicolas Dichtel
> Cc: Phil Sutter
> Cc: Toshiaki Makita
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Vijay Pandurangan
Applied and queued up for -stable, thanks.
N§²ζμrΈyϊθΨb²X¬ΆΗ§vΨ^)ήΊ{.nΗ+·₯{±κηzX§Ά‘ά¨}©²Ζ
zΪ:+v¨Ύ«κηzZ+Κ+zf£’·h§~Ϋi�ϋΰzΉ �w₯’Έ?¨θΪ&’)ί’fω^jΗ«y§m
α@A«aΆΪ�
0Άμh�εi
net: user-controllable kmalloc size in __sctp_setsockopt_connectx
Hello,
The following program triggers WARNING in kmalloc:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
int main()
{
long r0 = syscall(SYS_mmap, 0x2000ul, 0x4000ul, 0x3ul,
0x32ul, 0xul, 0x0ul);
long r1 = syscall(SYS_socket, 0x2ul, 0x80801ul, 0x84ul, 0, 0, 0);
*(uint32_t*)0x20002fb0 = (uint32_t)0x5fb;
*(uint32_t*)0x20002fb4 = (uint32_t)0x;
*(uint32_t*)0x20002fb8 = (uint32_t)0x0;
*(uint32_t*)0x20002fbc = (uint32_t)0x0;
*(uint32_t*)0x20002fc0 = (uint32_t)0x;
*(uint16_t*)0x20002fc4 = (uint16_t)0x7;
*(uint16_t*)0x20002fc6 = (uint16_t)0x8;
*(uint64_t*)0x20002fc8 = (uint64_t)0xa1d;
*(uint64_t*)0x20002fd0 = (uint64_t)0xd775;
*(uint64_t*)0x20002fd8 = (uint64_t)0x9;
*(uint64_t*)0x20002fe0 = (uint64_t)0x26;
*(uint64_t*)0x20002fe8 = (uint64_t)0x2;
*(uint64_t*)0x20002ff0 = (uint64_t)0x997;
*(uint32_t*)0x20002ff8 = (uint32_t)0x0;
*(uint32_t*)0x20002ffc = (uint32_t)0x;
long r17 = syscall(SYS_msgctl, 0xul, 0xbul,
0x20002fb0ul, 0, 0, 0);
memcpy((void*)0x20001000,
"\xc4\xcb\x30\xad\x58\x07\xa7\x93\x4f\xba\x75\x75\x33\x9a\x9b\x14\x36\x28\x6d\xc6\x57\x57\xc0\x17\x3b\x03\x6e\xe8\xbd\x31\x99\x17\x1b\x18\xcb\x05\x31\x3b\xc5\x39\xda\xdf\x1f\x9f\x1f\xd0\x1c\xd4\xce\x04\x1c\x00\xa0\x0b\xf8\x13\xd6\x93\xbd\x43\x33\xcb\x6d\x18\x8f\xab\x15\x59\x79\x63\x0d\x3d\x8d\x11\xd4\xd5\x07",
77);
long r19 = syscall(SYS_msgsnd, 0x0ul, 0x20001000ul, 0x800ul, 0, 0, 0);
long r20 = syscall(SYS_getsockopt, r1, 0x84ul, 0x6ful,
0x20002fcbul, 0x2ffful, 0);
return 0;
}
[ cut here ]
WARNING: CPU: 3 PID: 6724 at mm/page_alloc.c:2989
__alloc_pages_nodemask+0x771/0x15f0()
Modules linked in:
CPU: 3 PID: 6724 Comm: a.out Not tainted 4.4.0-rc6+ #173
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
880069a276d0 82899ffd
880064124680 85deedc0 880069a27710 812ebbb9
815f8f81 85deedc0 0bad 880069a27998
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
[] warn_slowpath_common+0xd9/0x140 kernel/panic.c:460
[] warn_slowpath_null+0x29/0x30 kernel/panic.c:493
[< inline >] __alloc_pages_slowpath mm/page_alloc.c:2989
[] __alloc_pages_nodemask+0x771/0x15f0 mm/page_alloc.c:3235
[] alloc_pages_current+0xee/0x340 mm/mempolicy.c:2055
[< inline >] alloc_pages include/linux/gfp.h:451
[] alloc_kmem_pages+0x16/0xf0 mm/page_alloc.c:3414
[] kmalloc_order+0x1f/0x80 mm/slab_common.c:1007
[] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1018
[< inline >] kmalloc_large include/linux/slab.h:390
[] __kmalloc+0x2de/0x330 mm/slub.c:3555
[< inline >] kmalloc include/linux/slab.h:463
[] __sctp_setsockopt_connectx+0xc6/0x150
net/sctp/socket.c:1318
[< inline >] sctp_getsockopt_connectx3 net/sctp/socket.c:1410
[] sctp_getsockopt+0x25ee/0x3e00 net/sctp/socket.c:6007
[] sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2601
[< inline >] SYSC_getsockopt net/socket.c:1782
[] SyS_getsockopt+0x142/0x230 net/socket.c:1764
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
---[ end trace 142fd9e8ed8bda1f ]---
On commit 4ef7675344d687a0ef5b0d7c0cee12da005870c0 (Dec 20).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/77] More fixes, cleanup and modernization for NCR5380 drivers
On Tuesday 22 December 2015 02:17:38 Finn Thain wrote: > > Like my previous work on the NCR5380 drivers, this patch series has bug > fixes, code cleanup and modernization. These drivers suffer from mistakes, > poor style and neglect and this long series addresses the worst of it, > covering all ten wrapper drivers and both of the core driver forks. The > combined size of the drivers is reduced by over 700 LoC. > > This series continues to reduce divergence between the two core driver > forks, often by copying a bug fix from one to the other. Most patches are > larger for having to keep the two forks in sync. Making the same change to > both is churn if one of them is to be removed but neither can be as yet. > By the end of this series the diff between the two forks is minimal, so it > becomes clear what caused the fork and what can be done about it. > > This patch series did benefit from scripts/checkpatch.pl but not too much. > Decades ago, these drivers started out with 4-space tabs and if the 80 > column limit were to be strictly enforced now, it would require adding new > functions and shortening identifiers. I would defer this sort of activity > until after the fork has been resolved. > > All patches to all NCR5380 drivers (x86, ARM, m68k) have been compile- > tested. The mac_scsi, dmx3191d, g_NCR5380 and atari_scsi modules were > regression tested on suitable hardware. Tested on HP C2502 (53C400A chip), Canon FG2-5202 (53C400 chip) and DTC-3181L (DTCT-436P chip) ISA cards - everything works fine! Thanks. Tested-by: Ondrej Zary -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] tcp/ipv4: kernel panic because of (possible) division by zero
That is correct, I have net.ipv4.tcp_ecn set to 1. I've recompiled the kernel with proposed patch, now still waiting for issue to be triggered. Could I manually simulate the erroneous TCP ECN behavior to speed up the debugging? On понеділок, 21 грудня 2015 р. 18:10:32 EET Yuchung Cheng wrote: > On Mon, Dec 21, 2015 at 12:25 PM, Oleksandr Natalenko > > wrote: > > Commit 3759824da87b30ce7a35b4873b62b0ba38905ef5 (tcp: PRR uses CRB mode by > > default and SS mode conditionally) introduced changes to > > net/ipv4/tcp_input.c tcp_cwnd_reduction() that, possibly, cause division > > by zero, and therefore, kernel panic in interrupt handler [1]. > > > > Reverting 3759824da87b30ce7a35b4873b62b0ba38905ef5 seems to fix the issue. > > > > I'm able to reproduce the issue on 4.3.0–4.3.3 once per several day > > (occasionally). > > > > What could be done to help in debugging this issue? > > Do you have ECN enabled (i.e. sysctl net.ipv4.tcp_ecn > 0)? > > If so I suspect an ACK carrying ECE during CA_Loss causes entering CWR > state w/o calling tcp_init_cwnd_reduct() to set tp->prior_cwnd. Can > you try this debug / quick-fix patch and send me the error message if > any? > > > Regards, > > > > Oleksandr. > > > > [1] http://i.piccy.info/ > > i9/6f5cb187c4ff282d189f78c63f95af43/1450729403/283985/951663/panic.jpg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/5] mmc: shdci-bcm2835: add verify for 32-bit back-to-back workaround
Hi Scott,
Am 22.12.2015 um 20:23 schrieb Scott Branden:
Hi Stefan,
On 15-12-22 07:55 AM, Stefan Wahren wrote:
Hi Scott,
Am 07.11.2014 um 19:31 schrieb Scott Branden:
On 14-11-05 09:01 PM, Stephen Warren wrote:
On 11/05/2014 12:00 AM, Scott Branden wrote:
On 14-11-04 08:59 PM, Stephen Warren wrote:
On 10/30/2014 12:36 AM, Scott Branden wrote:
Add a verify option to driver to print out an error message if a
potential back to back write could cause a clock domain issue.
index f8c450a..11af27f 100644
+#ifdef CONFIG_MMC_SDHCI_BCM2835_VERIFY_WORKAROUND
+struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+struct bcm2835_sdhci_host *bcm2835_host = pltfm_host->priv;
+
+if (bcm2835_host->previous_reg == reg) {
+if ((reg != SDHCI_HOST_CONTROL)
+&& (reg != SDHCI_CLOCK_CONTROL)) {
The comment in patch 3 says the problem doesn't apply to the data
register. Why does this check for these two registers rather than
data?
This Verify workaround patch still a work in progress. I'm still
getting more info from the silicon designers on the back-to-back
register writes that are affect. The spew of 0x20 or 0x28 or 0x2c
register writes are all ok locations that don't need to be worked
around. This patch needs to be corrected with the proper register
rules
still.
Thanks for testing. Yes, I have work to do on the verify patch above
still.
do you still have plans to submit a V3 of this patch series?
No, I do not have plans to submit a V3 of this patch series.
I submitted this patch as RPI has a similar controller to the SoCs I am
familiar with as well as needing similar work arounds You can take
over the patchset. Or, try and get the sdhci-iproc.c driver going on
RPI. The sdhci-iproc is the production driver we use on a variety of
SoCs and support and test this driver.
after applying the patch series both drivers are very similiar so i
prefer the latter. I will give it a try. Thanks for the hint about
sdhci-iproc.
Regards
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the gpio tree
Hi Linus,
On Tue, 22 Dec 2015 10:08:58 +0100 Linus Walleij
wrote:
>
> On Tue, Dec 22, 2015 at 7:57 AM, Robert Jarzmik
> wrote:
> > Stephen Rothwell writes:
> >
> >> After merging the gpio tree, today's linux-next build (lots without
> >> CONFIG_OF) failed like this:
> >>
> >> drivers/gpio/gpio-pxa.c: In function 'pxa_gpio_probe':
> >> drivers/gpio/gpio-pxa.c:648:12: error: 'pxa_irq_domain_ops' undeclared
> >> (first use in this function)
> >>
> >> Caused by commit
> >>
> >> 384ca3c6a28d ("gpio: pxa: change the interrupt management")
> >>
> >> The reference to pxa_irq_domain_ops was moved out of the protection of
> >> CONFIG_OF ...
> >>
> >> Discovered after the release.
> >
> > Hi Stephen,
> >
> > The fix has been sent in
> > http://www.spinics.net/lists/kernel/msg2147774.html but
> > did not reach Linus's next tree yet probably.
>
> Sorry, I'll pick it now-ish...
Not in the published gpio tree, yet?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel] vfio: Add explicit alignments in vfio_iommu_spapr_tce_create
On Fri, 2015-12-18 at 12:35 +1100, Alexey Kardashevskiy wrote:
> The vfio_iommu_spapr_tce_create struct has 4x32bit and 2x64bit fields
> which should have resulted in sizeof(fio_iommu_spapr_tce_create)
> equal
> to 32 bytes. However due to the gcc's default alignment, the actual
> size of this struct is 40 bytes.
>
> This fills gaps with __resv1/2 fields.
>
> This should not cause any change in behavior.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
Applied to next for v4.5 with David's ack. Thanks!
Alex
> include/uapi/linux/vfio.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 9fd7b5d..d117233 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -568,8 +568,10 @@ struct vfio_iommu_spapr_tce_create {
> __u32 flags;
> /* in */
> __u32 page_shift;
> + __u32 __resv1;
> __u64 window_size;
> __u32 levels;
> + __u32 __resv2;
> /* out */
> __u64 start_addr;
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/4] x86/efi: show actual ending addresses in efi_print_memmap
--- Robert Elliott, HPE Persistent Memory > -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Matt Fleming > Sent: Monday, December 21, 2015 10:06 AM > To: Elliott, Robert (Persistent Memory) > Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 1/4] x86/efi: show actual ending addresses in > efi_print_memmap > > On Mon, 21 Dec, at 03:50:38PM, Matt Fleming wrote: > > On Thu, 17 Dec, at 07:28:31PM, Robert Elliott wrote: > > > Adjust efi_print_memmap to print the real end address of each > > > range, not 1 byte beyond. This matches other prints like those for > > > SRAT and nosave memory. > > > > > > Change the closing ) to ] to match the opening [. > > > > > > old: > > > efi: mem61: [Persistent Memory | | | | | | | > |WB|WT|WC|UC] range=[0x00088000-0x000c8000) (16384MB) > > > > > > new: > > > efi: mem61: [Persistent Memory | | | | | | | > |WB|WT|WC|UC] range=[0x00088000-0x000c7fff] (16384MB) > > > > > > Example other address range prints: > > > SRAT: Node 1 PXM 1 [mem 0x48000-0x87fff] > > > PM: Registered nosave memory: [mem 0x88000-0xc7fff] > > > > > > Signed-off-by: Robert Elliott > > > --- > > > arch/x86/platform/efi/efi.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > Is this change purely for aesthetic reasons? We're usually not in the > > habit of changing the output of print messages without a good reason > > because people downstream do rely on them being consistent. > > I just noticed the bracket change. > > My comment above only refers to printing the range addresses. Swapping > ')' for ']' is a perfectly valid change. While investigating the grub persistent memory corruption issues, it was helpful to make this table match the ending address convention used by: * the kernel's e820 table prints * the kernel's nosave memory prints * grub's lsmmap and lsefimmap commands * the UEFI shell's memmap command Using the excerpts from the patch, if you grep all the various logs for c7fff, you won't find the line with c8000. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization
On 22 December 2015 at 21:01, Christoph Lameter wrote: > On Tue, 22 Dec 2015, Mathias Krause wrote: > >> How many systems, do you think, are running with enabled DEBUG_SLAB / >> SLUB_DEBUG in production? Not so many, I'd guess. And the ones running >> into issues probably just disable DEBUG_SLAB / SLUB_DEBUG. > > All systems run with SLUB_DEBUG in production. SLUB_DEBUG causes the code > for debugging to be compiled in. Then it can be enabled later with a > command line parameter. Indeed, I meant CONFIG_SLUB_DEBUG_ON, i.e. compiled in and enabled SLAB cache debugging including poisoning. Regards, Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net-sysfs: use to_net_dev in net_namespace()
From: Geliang Tang Date: Tue, 22 Dec 2015 23:11:49 +0800 > Use to_net_dev() instead of open-coding it. > > Signed-off-by: Geliang Tang Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX
On 12/22/15 8:08 AM, Christoph Lameter wrote: On Mon, 21 Dec 2015, Laura Abbott wrote: The biggest change from PAX_MEMORY_SANTIIZE is that this feature sanitizes the SL[AOU]B allocators only. My plan is to work on the buddy allocator santization after this series gets picked up. A side effect of this is that allocations which go directly to the buddy allocator (i.e. large allocations) aren't sanitized. I'd like feedback about whether it's worth it to add sanitization on that path directly or just use the page allocator sanitization when that comes in. I am not sure what the point of this patchset is. We have a similar effect to sanitization already in the allocators through two mechanisms: 1. Slab poisoning 2. Allocation with GFP_ZERO I do not think we need a third one. You could accomplish your goals much easier without this code churn by either 1. Improve the existing poisoning mechanism. Ensure that there are no gaps. Security sensitive kernel slab caches can then be created with the POISONING flag set. Maybe add a Kconfig flag that enables POISONING for each cache? What was the issue when you tried using posining for sanitization? The existing poisoning does work for sanitization but it's still a debug feature. It seemed more appropriate to keep debug features and non-debug features separate hence the separate option and configuration. 2. Add a mechanism that ensures that GFP_ZERO is set for each allocation. That way every object you retrieve is zeroed and thus you have implied sanitization. This also can be done in a rather simple way by changing the GFP_KERNEL etc constants to include __GFP_ZERO depending on a Kconfig option. Or add some runtime setting of the gfp flags somewhere. That's good for allocation but sanitization is done on free. The goal is to reduce any leftover data that might be around while on an unallocated slab. Generally I would favor option #2 if you must have sanitization because that is the only option to really give you a deterministic content of object on each allocation. Any half way measures would not work I think. Note also that most allocations are already either allocations that zero the content or they are immediately initializing the content of the allocated object. After all the object is not really usable if the content is random. You may be able to avoid this whole endeavor by auditing the kernel for locations where the object is not initialized after allocation. Once one recognizes the above it seems that sanitization is pretty useless. Its just another pass of writing zeroes before the allocator or uer of the allocated object sets up deterministic content of the object or -- in most cases -- zeroes it again. The sanitization is going towards kernel hardening which is designed to help keep the kernel secure even when programmers screwed up. Auditing still won't catch everything. sanitization is going towards the idea of kernel self-protection which is what Grsecurity is known for and Kees Cook is trying to promote for mainline (http://lwn.net/Articles/662219/) Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] resource: Add System RAM resource type
On Tue, 2015-12-22 at 12:34 +0100, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote: > > This scheme may have a problem, though. For instance, when someone > > writes a loadable module that searches for "foo", but the "foo" entry > > may be initialized in a distro kernel/driver that cannot be modified. > > Since this search is only necessary to obtain a range initialized by > > other module, this scenario is likely to happen. We no longer have > > ability to search for a new entry unless we modify the code that > > initializes the entry first. > > Since when do we pay attention to out-of-tree modules which cannot be > changed? The above example referred the case with distros, not with the upstream. That is, one writes a new loadable module and makes it available in the upstream. Then s/he makes it work on a distro used by the customers, but may or may not be able to change the distro kernel/drivers used by the customers. > Regardless, we don't necessarily need to change the callers - we could > add new ones of the form walk_iomem_resource_by_type() or whatever its > name is going to be which uses the ->type attribute of the resource and > phase out the old ones slowly. New code will call the better interfaces, > we should probably even add a checkpatch rule to check for that. I agree that we can add new interfaces with the type check. This 'type' may need some clarification since it is an assigned type, which is different from I/O resource type. That is, "System RAM" is an I/O resource type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an assigned type to a particular range of System RAM. A range may be associated with multiple names, so as multiple assigned types. For lack of a better idea, I may call it 'assign_type'. I am open for a better name. > > Even if we avoid strcmp() with @name in the kernel, user applications > > will continue to use @name since that is the only type available in > > /proc/iomem. For instance, kexec has its own search function with a > > string name. > > See above. > > > When a new commonly-used search name comes up, we can define it as a > > new extended I/O resource type similar to IORESOURCE_SYSTEM_RAM. For > > the current remaining cases, i.e. crash, kexec, and einj, they have no > > impact to performance. Leaving these special cases aside will keep the > > ability to search for any entry without changing the kernel, and save > > some memory space from adding the new 'type'. > > Again, we can leave the old interfaces at peace but going forward, we > should make the searching for resources saner and stop using silly > strings. OK, I will try to convert the existing callers with the new interfaces. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert "kernel/stop_machine.c: remove CONFIG_SMP dependencies"
Hi Andrew, On Mon, 21 Dec 2015 22:59:45 -0800 Andrew Morton wrote: > > On Tue, 22 Dec 2015 11:30:51 +0530 Sudip Mukherjee > wrote: > > > > Rationale: > > > > > > stop_machine.o is only built when CONFIG_SMP=y so > > > > > > #if defined(CONFIG_SMP) || defined(CONFIG_HOTPLUG_CPU) > > > > > > always evaluates to true, so remove it. > > > > Hi Andrew, > > The error is still there. I guess you have been busy. :) > > > > next-20151222 fails with the same error. You can see the m32r defconfig > > at https://travis-ci.org/sudipm-mukherjee/parport/jobs/98258267 > > I forgot to Cc Stephen :( I wish I had figured this out earlier - last nights build were a blood bath :-( Anyway, I applied it for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization
On Tue, 22 Dec 2015, Mathias Krause wrote: > How many systems, do you think, are running with enabled DEBUG_SLAB / > SLUB_DEBUG in production? Not so many, I'd guess. And the ones running > into issues probably just disable DEBUG_SLAB / SLUB_DEBUG. All systems run with SLUB_DEBUG in production. SLUB_DEBUG causes the code for debugging to be compiled in. Then it can be enabled later with a command line parameter. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/5] x86/events: Move perf_event_amd_ibs.c
From: Borislav Petkov
Signed-off-by: Borislav Petkov
---
arch/x86/events/Makefile | 1 +
arch/x86/{kernel/cpu/perf_event_amd_ibs.c => events/amd/ibs.c} | 2 +-
arch/x86/kernel/cpu/Makefile | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
rename arch/x86/{kernel/cpu/perf_event_amd_ibs.c => events/amd/ibs.c} (99%)
diff --git a/arch/x86/events/Makefile b/arch/x86/events/Makefile
index e0560b6dd77b..88f787350bf0 100644
--- a/arch/x86/events/Makefile
+++ b/arch/x86/events/Makefile
@@ -1,3 +1,4 @@
obj-y += core.o
obj-$(CONFIG_CPU_SUP_AMD) += amd/core.o
+obj-$(CONFIG_X86_LOCAL_APIC)+= amd/ibs.o
diff --git a/arch/x86/kernel/cpu/perf_event_amd_ibs.c
b/arch/x86/events/amd/ibs.c
similarity index 99%
rename from arch/x86/kernel/cpu/perf_event_amd_ibs.c
rename to arch/x86/events/amd/ibs.c
index 989d3c215d2b..3531d617ba3a 100644
--- a/arch/x86/kernel/cpu/perf_event_amd_ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -14,7 +14,7 @@
#include
-#include "perf_event.h"
+#include "../../kernel/cpu/perf_event.h"
static u32 ibs_caps;
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 66524a343c13..395cd5148cc1 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -55,7 +55,7 @@ obj-$(CONFIG_X86_MCE) += mcheck/
obj-$(CONFIG_MTRR) += mtrr/
obj-$(CONFIG_MICROCODE)+= microcode/
-obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o
perf_event_amd_ibs.o
+obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o
obj-$(CONFIG_HYPERVISOR_GUEST) += vmware.o hypervisor.o mshyperv.o
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 5/5] x86/events: Move perf_event_amd_uncore.c
From: Borislav Petkov
Signed-off-by: Borislav Petkov
---
arch/x86/events/Makefile | 2 +-
arch/x86/{kernel/cpu/perf_event_amd_uncore.c => events/amd/uncore.c} | 0
arch/x86/kernel/cpu/Makefile | 1 -
3 files changed, 1 insertion(+), 2 deletions(-)
rename arch/x86/{kernel/cpu/perf_event_amd_uncore.c => events/amd/uncore.c}
(100%)
diff --git a/arch/x86/events/Makefile b/arch/x86/events/Makefile
index 838195d90961..7d1ecff583b0 100644
--- a/arch/x86/events/Makefile
+++ b/arch/x86/events/Makefile
@@ -1,6 +1,6 @@
obj-y += core.o
-obj-$(CONFIG_CPU_SUP_AMD) += amd/core.o
+obj-$(CONFIG_CPU_SUP_AMD) += amd/core.o amd/uncore.o
obj-$(CONFIG_X86_LOCAL_APIC)+= amd/ibs.o
ifdef CONFIG_AMD_IOMMU
obj-$(CONFIG_CPU_SUP_AMD) += amd/iommu.o
diff --git a/arch/x86/kernel/cpu/perf_event_amd_uncore.c
b/arch/x86/events/amd/uncore.c
similarity index 100%
rename from arch/x86/kernel/cpu/perf_event_amd_uncore.c
rename to arch/x86/events/amd/uncore.c
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 86aa9ac6bd03..3b658812803b 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -31,7 +31,6 @@ obj-$(CONFIG_CPU_SUP_TRANSMETA_32)+= transmeta.o
obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
ifdef CONFIG_PERF_EVENTS
-obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_uncore.o
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_knc.o
perf_event_p4.o
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_lbr.o
perf_event_intel_ds.o perf_event_intel.o
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_rapl.o
perf_event_intel_cqm.o
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IMA: policy can be updated zero times
On Tue, 2015-12-22 at 08:51 -0500, Sasha Levin wrote:
> Commit "IMA: policy can now be updated multiple times" assumed that the
> policy would be updated at least once.
>
> If there are zero updates, the temporary list head object will get added
> to the policy list, and later dereferenced as an IMA policy object, which
> means that invalid memory will be accessed.
>
> Signed-off-by: Sasha Levin
> ---
> security/integrity/ima/ima_policy.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/security/integrity/ima/ima_policy.c
> b/security/integrity/ima/ima_policy.c
> index ba5d2fc..9b958b8 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -431,6 +431,9 @@ void ima_update_policy(void)
> {
> struct list_head *first, *last, *policy;
>
> + if (list_empty(_temp_rules))
> + return;
> +
> /* append current policy with the new rules */
> first = (_temp_rules)->next;
> last = (_temp_rules)->prev;
Thanks, Sasha. By the time ima_update_policy() is called
ima_release_policy() has already output the policy update status
message. I guess an empty policy could be considered a valid policy.
Could you add a msg indicating that the new policy was empty?
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: defconfig for 4.5 #1
On Wed, Dec 16, 2015 at 11:20:26AM +0100, Nicolas Ferre wrote: > Arnd, Olof, Kevin, > > As single patch for this pull-request: tell me if you would like to take it > independently, as a patch. > > Thanks, best regards, > > The following changes since commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8: > > Linux 4.4-rc3 (2015-11-29 18:58:26 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git > tags/at91-defconfig > > for you to fetch changes up to 94c2317cf46a9c137650bf30f2aba7271886c0b4: > > ARM: at91/defconfig: enable watchdog drivers in sama5_defconfig (2015-12-15 > 11:18:39 +0100) Merged, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: multi_v7_defconfig: Enable fan, sensors and audio for Odroid XU3
On Thu, Dec 17, 2015 at 08:50:24PM +0900, Krzysztof Kozlowski wrote: > 2015-12-07 18:43 GMT+09:00 Arnd Bergmann : > > On Monday 07 December 2015 18:38:44 Krzysztof Kozlowski wrote: > >> On 07.12.2015 18:14, Arnd Bergmann wrote: > >> > On Monday 07 December 2015 09:59:54 Krzysztof Kozlowski wrote: > >> >> For Odroid XU3-family enable the: > >> >> - PWM fan (to control the CPU fan using thermal subsystem), > >> >> - TI INA231 sensors (provide power measurements of big.LITTLE cores, > >> >>DRAM and GPU), > >> >> - Samsung sound (for Odroid XU3 and Snow as well). > >> >> > >> >> Signed-off-by: Krzysztof Kozlowski > >> >> > >> > > >> > Looks good. Do you have a samsung/defconfig branch already that you > >> > can put this into, or should be pick it up into arm-soc directly? > >> > > >> > My preference is the former, but it would be a bit silly if that > >> > is the only samsung defconfig change we need. > >> > >> I had a couple of defconfig patches in my queue but I sent them last > >> week to Kukjin in pull request. He didn't pull it yet. Maybe he could > >> apply this patch after pulling? > >> > >> Anyway we can wait for a few days to sort it out. If I don't have > >> another defconfig patches then I will remind myself with applying it to > >> arm-soc. > >> > > > > Ok, sounds good. > > +Cc a...@kernel.org, > > I don't have any other defconfig changes in my queue, except of course > stuff which I sent in pull request. I mean the request sent initially > to Kukjin but now redirected with his ack to you guys. > > If you don't mind, please apply this patch directly (with Javier's > reviewed-by). Happy to apply, but can you please resend it to us (in patch format is fine) since I just get this email from the thread in the arm@ folder... -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: dt for 4.5 #1
On Wed, Dec 16, 2015 at 11:14:16AM +0100, Nicolas Ferre wrote: > Arnd, Olof, Kevin, > > This is the first PR for AT91 DT material targeted to 4.5. The main part is > the > addition for the new DENX platform. Other things are simply basic fixes and > updates. > > Thanks, best regards, > > The following changes since commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8: > > Linux 4.4-rc3 (2015-11-29 18:58:26 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git > tags/at91-dt > > for you to fetch changes up to 0a804b5729bb0021e63662b772db0f52de653056: > > ARM: at91/dt: sama5d2 Xplained: pmic needs a specific sda hold time > (2015-12-15 12:23:32 +0100) Merged, thanks. Btw, most other platforms use: ARM: dts: at91: ... for format, so feel free to switch to that in the future. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 4/5] x86/events: Move perf_event_amd_iommu.*
From: Borislav Petkov
Cc: Joerg Roedel
Signed-off-by: Borislav Petkov
---
arch/x86/events/Makefile | 3 +++
arch/x86/{kernel/cpu/perf_event_amd_iommu.c => events/amd/iommu.c} | 4 ++--
arch/x86/{kernel/cpu/perf_event_amd_iommu.h => events/amd/iommu.h} | 0
arch/x86/kernel/cpu/Makefile | 3 ---
4 files changed, 5 insertions(+), 5 deletions(-)
rename arch/x86/{kernel/cpu/perf_event_amd_iommu.c => events/amd/iommu.c} (99%)
rename arch/x86/{kernel/cpu/perf_event_amd_iommu.h => events/amd/iommu.h}
(100%)
diff --git a/arch/x86/events/Makefile b/arch/x86/events/Makefile
index 88f787350bf0..838195d90961 100644
--- a/arch/x86/events/Makefile
+++ b/arch/x86/events/Makefile
@@ -2,3 +2,6 @@ obj-y += core.o
obj-$(CONFIG_CPU_SUP_AMD) += amd/core.o
obj-$(CONFIG_X86_LOCAL_APIC)+= amd/ibs.o
+ifdef CONFIG_AMD_IOMMU
+obj-$(CONFIG_CPU_SUP_AMD) += amd/iommu.o
+endif
diff --git a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
b/arch/x86/events/amd/iommu.c
similarity index 99%
rename from arch/x86/kernel/cpu/perf_event_amd_iommu.c
rename to arch/x86/events/amd/iommu.c
index 97242a9242bd..629bc700eb08 100644
--- a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
+++ b/arch/x86/events/amd/iommu.c
@@ -16,8 +16,8 @@
#include
#include
-#include "perf_event.h"
-#include "perf_event_amd_iommu.h"
+#include "../../kernel/cpu/perf_event.h"
+#include "iommu.h"
#define COUNTER_SHIFT 16
diff --git a/arch/x86/kernel/cpu/perf_event_amd_iommu.h
b/arch/x86/events/amd/iommu.h
similarity index 100%
rename from arch/x86/kernel/cpu/perf_event_amd_iommu.h
rename to arch/x86/events/amd/iommu.h
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 395cd5148cc1..86aa9ac6bd03 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -32,9 +32,6 @@ obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
ifdef CONFIG_PERF_EVENTS
obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_uncore.o
-ifdef CONFIG_AMD_IOMMU
-obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_iommu.o
-endif
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_knc.o
perf_event_p4.o
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_lbr.o
perf_event_intel_ds.o perf_event_intel.o
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_rapl.o
perf_event_intel_cqm.o
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/5] x86/events: Move perf_event_amd.c
From: Borislav Petkov
Signed-off-by: Borislav Petkov
---
arch/x86/events/Makefile| 2 ++
arch/x86/{kernel/cpu/perf_event_amd.c => events/amd/core.c} | 2 +-
arch/x86/kernel/cpu/Makefile| 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
rename arch/x86/{kernel/cpu/perf_event_amd.c => events/amd/core.c} (99%)
diff --git a/arch/x86/events/Makefile b/arch/x86/events/Makefile
index 3fad3ce1bbab..e0560b6dd77b 100644
--- a/arch/x86/events/Makefile
+++ b/arch/x86/events/Makefile
@@ -1 +1,3 @@
obj-y += core.o
+
+obj-$(CONFIG_CPU_SUP_AMD) += amd/core.o
diff --git a/arch/x86/kernel/cpu/perf_event_amd.c b/arch/x86/events/amd/core.c
similarity index 99%
rename from arch/x86/kernel/cpu/perf_event_amd.c
rename to arch/x86/events/amd/core.c
index 3ea177cb7366..53e04f58d773 100644
--- a/arch/x86/kernel/cpu/perf_event_amd.c
+++ b/arch/x86/events/amd/core.c
@@ -5,7 +5,7 @@
#include
#include
-#include "perf_event.h"
+#include "../../kernel/cpu/perf_event.h"
static __initconst const u64 amd_hw_cache_event_ids
[PERF_COUNT_HW_CACHE_MAX]
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 89d9b1f84ac3..66524a343c13 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -31,7 +31,7 @@ obj-$(CONFIG_CPU_SUP_TRANSMETA_32)+= transmeta.o
obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
ifdef CONFIG_PERF_EVENTS
-obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd.o
perf_event_amd_uncore.o
+obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_uncore.o
ifdef CONFIG_AMD_IOMMU
obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_iommu.o
endif
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/5] x86/events: Move perf_event.c
From: Borislav Petkov
Also, keep the churn at minimum by adjusting the include "perf_event.h"
when each file gets moved.
Signed-off-by: Borislav Petkov
---
arch/x86/Kbuild | 3 ++-
arch/x86/events/Makefile| 1 +
arch/x86/{kernel/cpu/perf_event.c => events/core.c} | 2 +-
arch/x86/kernel/cpu/Makefile| 2 --
4 files changed, 4 insertions(+), 4 deletions(-)
create mode 100644 arch/x86/events/Makefile
rename arch/x86/{kernel/cpu/perf_event.c => events/core.c} (99%)
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 1538562cc720..eb3abf8ac44e 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -1,6 +1,7 @@
-
obj-y += entry/
+obj-$(CONFIG_PERF_EVENTS) += events/
+
obj-$(CONFIG_KVM) += kvm/
# Xen paravirtualization support
diff --git a/arch/x86/events/Makefile b/arch/x86/events/Makefile
new file mode 100644
index ..3fad3ce1bbab
--- /dev/null
+++ b/arch/x86/events/Makefile
@@ -0,0 +1 @@
+obj-y += core.o
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/events/core.c
similarity index 99%
rename from arch/x86/kernel/cpu/perf_event.c
rename to arch/x86/events/core.c
index 9dfbba5ce6e8..ccbf7242307c 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/events/core.c
@@ -37,7 +37,7 @@
#include
#include
-#include "perf_event.h"
+#include "../kernel/cpu/perf_event.h"
struct x86_pmu x86_pmu __read_mostly;
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index b3292a4b37c1..89d9b1f84ac3 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -30,8 +30,6 @@ obj-$(CONFIG_CPU_SUP_CENTAUR) += centaur.o
obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
-obj-$(CONFIG_PERF_EVENTS) += perf_event.o
-
ifdef CONFIG_PERF_EVENTS
obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd.o
perf_event_amd_uncore.o
ifdef CONFIG_AMD_IOMMU
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/5] perf: Sanitize perf directory structure, p1
From: Borislav Petkov
Hi guys,
so what better time to do that fun than during the holidays when no one
else is producing patches. :-)
Anyway, here's a part one conversion of the AMD perf events facilities.
Directory structure looks like this:
arch/x86/events/
|-- amd
| |-- core.c
| |-- ibs.c
| |-- iommu.c
| |-- iommu.h
| `-- uncore.c
|-- core.c
`-- Makefile
and I've kept the churn at a mininum. Holler if something's not kosher.
Thanks.
Borislav Petkov (5):
x86/events: Move perf_event.c
x86/events: Move perf_event_amd.c
x86/events: Move perf_event_amd_ibs.c
x86/events: Move perf_event_amd_iommu.*
x86/events: Move perf_event_amd_uncore.c
arch/x86/Kbuild | 3 ++-
arch/x86/events/Makefile | 7 +++
arch/x86/{kernel/cpu/perf_event_amd.c => events/amd/core.c} | 2 +-
arch/x86/{kernel/cpu/perf_event_amd_ibs.c => events/amd/ibs.c}| 2 +-
.../x86/{kernel/cpu/perf_event_amd_iommu.c => events/amd/iommu.c} | 4 ++--
.../x86/{kernel/cpu/perf_event_amd_iommu.h => events/amd/iommu.h} | 0
.../{kernel/cpu/perf_event_amd_uncore.c => events/amd/uncore.c} | 0
arch/x86/{kernel/cpu/perf_event.c => events/core.c} | 2 +-
arch/x86/kernel/cpu/Makefile | 8 +---
9 files changed, 15 insertions(+), 13 deletions(-)
create mode 100644 arch/x86/events/Makefile
rename arch/x86/{kernel/cpu/perf_event_amd.c => events/amd/core.c} (99%)
rename arch/x86/{kernel/cpu/perf_event_amd_ibs.c => events/amd/ibs.c} (99%)
rename arch/x86/{kernel/cpu/perf_event_amd_iommu.c => events/amd/iommu.c} (99%)
rename arch/x86/{kernel/cpu/perf_event_amd_iommu.h => events/amd/iommu.h}
(100%)
rename arch/x86/{kernel/cpu/perf_event_amd_uncore.c => events/amd/uncore.c}
(100%)
rename arch/x86/{kernel/cpu/perf_event.c => events/core.c} (99%)
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
2015-12-22 07:19+, Wu, Feng:
>> From: Yang Zhang [mailto:yang.zhang...@gmail.com]
>> On 2015/12/22 14:59, Wu, Feng wrote:
>> >> From: Yang Zhang [mailto:yang.zhang...@gmail.com]
>> >> On 2015/12/16 9:37, Feng Wu wrote:
>> >>> +for_each_set_bit(i, , 16) {
>> >>> +if (!dst[i]
>> >> && !kvm_lapic_enabled(dst[i]->vcpu)) {
>> >>
>> >> It should be or(||) not and (&&).
>> >
>> > Oh, you are right! My negligence! Thanks for pointing this out, Yang!
>>
>> btw, i think the kvm_lapic_enabled check is wrong here? Why need it
>> here?
>> >>>
>> >>> If the lapic is not enabled, I think we cannot recognize it as a
>> >>> candidate, can
>> >> we?
>> >>> Maybe Radim can confirm this, Radim, what is your option?
SDM 10.6.2.2 Logical Destination Mode:
For both configurations of logical destination mode, when combined
with lowest priority delivery mode, software is responsible for
ensuring that all of the local APICs included in or addressed by the
IPI or I/O subsystem interrupt are present and enabled to receive the
interrupt.
The case is undefined if some targeted LAPICs weren't hardware enabled
as no interrupts can be delivered to hardware disabled LAPIC, so we can
check for hardware enabled.
It's not obvious if "enabled to receive the interrupt" means hardware or
software enabled, but lowest priority cannot deliver NMI/INIT/..., so
checking for software enabled doesn't restrict any valid uses either.
so ... KVM only musn't blow up when encountering this situation :)
The current code seems correct, but redundant. Just for reference, KVM
now does:
- check for software enabled LAPIC since patch aefd18f01ee8 ("KVM: x86:
In DM_LOWEST, only deliver interrupts to vcpus with enabled LAPIC's")
- check only for hardware enabled LAPIC in the fast path, since
1e08ec4a130e ("KVM: optimize apic interrupt delivery"))
(v1 was arguable better, I pointed the need for enabled LAPIC in v1 only
from looking at one KVM function, sorry.)
>> >> Lapic can be disable by hw or sw. Here we only need to check the hw is
>> >> enough which is already covered while injecting the interrupt into
>> >> guest. I remember we(Glab, Macelo and me) have discussed it several ago,
>> >> but i cannot find the mail thread.
>>
>> >
>> > But if the lapic is disabled by software, we cannot still inject
>> > interrupts to
>> > it, can we?
>>
>> Yes, We cannot inject the normal interrupt. But this already covered by
>> current logic and add a check here seems meaningless. Conversely, it may
>> do bad thing..
>>
>
> Let's wait for Radim/Paolo's opinions about this.
I'd pick whatever results in less code: this time it seems like checking
for hardware enabled LAPIC in both paths (implicitly in the fast path).
Maybe it can be done better, I haven't given it much thought.
We should revert aefd18f01ee8 at the same time, so our PI/non-PI slow
paths won't diverge -- I hope it wasn't fixing a bug :)
I'll review the series tomorrow, thanks for your patience.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Dec 22 (mm/memcontrol)
On 12/22/15 11:19, Andrew Morton wrote: > On Tue, 22 Dec 2015 10:15:37 -0800 Randy Dunlap wrote: > >> On 12/21/15 21:29, Stephen Rothwell wrote: >>> Hi all, >>> >>> Changes since 20151221: >>> >> >> on i386 or x86_64: >> >> when CONFIG_SLOB=y: >> >> ../mm/memcontrol.c: In function 'memcg_update_kmem_limit': >> ../mm/memcontrol.c:2974:3: error: implicit declaration of function >> 'memcg_online_kmem' [-Werror=implicit-function-declaration] >>ret = memcg_online_kmem(memcg); >>^ >> ../mm/memcontrol.c: In function 'mem_cgroup_css_alloc': >> ../mm/memcontrol.c:4229:2: error: too many arguments to function >> 'memcg_propagate_kmem' >> error = memcg_propagate_kmem(parent, memcg); >> ^ >> ../mm/memcontrol.c:2949:12: note: declared here >> static int memcg_propagate_kmem(struct mem_cgroup *memcg) >> ^ > > I can't reproduce this. config, please? > -- attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.4.0-rc6 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_FHANDLE is not set # CONFIG_USELIB is not set # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y # CONFIG_NO_HZ_FULL_ALL is not set # CONFIG_NO_HZ_FULL_SYSIDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING_GEN=y # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_RCU_EXPERT=y CONFIG_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_CONTEXT_TRACKING=y # CONFIG_CONTEXT_TRACKING_FORCE is not set CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FAST_NO_HZ is not set CONFIG_TREE_RCU_TRACE=y CONFIG_RCU_KTHREAD_PRIO=0 CONFIG_RCU_NOCB_CPU=y # CONFIG_RCU_NOCB_CPU_NONE is not set # CONFIG_RCU_NOCB_CPU_ZERO is not set CONFIG_RCU_NOCB_CPU_ALL=y # CONFIG_RCU_EXPEDITE_BOOT is not set # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_NMI_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y # CONFIG_INTEL_RDT is not set CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y # CONFIG_MEMCG_SWAP_ENABLED is not
Re: [PATCH 1/2] clk: samsung: exynos5422: add missing parent GSCL block clocks
Mike, On 22/12/15 19:44, Mike Turquette wrote: > This is superseded by the pull request found in Message-ID: > <5671a456.9030...@samsung.com>, correct? The two pull requests are based on same branch, first 2 commits are tagged with for-4.5-clk-exynos5420 tag and the whole branch is tagged as clk-samsung-4.5. I assumed it's fine to use just the below tag for arm-soc. >>> > > The following changes since commit >>> > > 9f9499ae8e6415cefc4fe0a96ad0e27864353c89: >>> > > >>> > > Linux 4.4-rc5 (2015-12-13 17:42:58 -0800) >>> > > >>> > > are available in the git repository at: >>> > > >>> > > git://linuxtv.org/snawrocki/samsung.git tags/for-4.5-clk-exynos5420 >>> > > >>> > > for you to fetch changes up to bee4f87f01dc30fcf9e05eb55b833f89fd9bb4f4: >>> > > >>> > > clk: samsung: exynos5420: add cpu clock configuration data and >>> > > instantiate cpu clock (2015-12-16 16:35:26 +0100) >>> > > >>> > > >>> > > Samsung exynos5420 SoC clk subsystem support updates: >>> > > instantiation of the cpu clocks and addition of the GSCL >>> > > IP parent clocks to the list of available consumer clocks. >>> > > >>> > > >>> > > Marek Szyprowski (1): >>> > > clk: samsung: exynos542x: add missing parent GSCL block clocks >>> > > >>> > > Thomas Abraham (1): >>> > > clk: samsung: exynos5420: add cpu clock configuration data and >>> > > instantiate cpu clock >>> > > >>> > > drivers/clk/samsung/clk-exynos5420.c | 66 >>> > > +--- >>> > > include/dt-bindings/clock/exynos5420.h |4 ++ >>> > > 2 files changed, 64 insertions(+), 6 deletions(-) -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/3] ARM: multi_v7_defconfig: Enable AM437x PMIC TPS65218
On Mon, Dec 14, 2015 at 12:42:59PM -0600, Nishanth Menon wrote:
> Enable PMIC for AM437x platforms such as AM437x-sk similar to commit
> a186cf10da84 ("ARM: omap2plus_defconfig: enable TPS65218 configs").
> This allows multi_v7_defconfig to boot up on AM437x-sk platform.
>
> Signed-off-by: Nishanth Menon
Applied, thanks.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] ARM: multi_v7_defconfig: Enable beaglebone PMIC TPS65217
On Wed, Dec 16, 2015 at 07:15:41PM +0530, Afzal Mohammed wrote:
> Hi,
>
> On Tue, Dec 15, 2015 at 08:49:07AM -0600, Nishanth Menon wrote:
> > On Tue, Dec 15, 2015 at 7:51 AM, Afzal Mohammed
> > wrote:
> > > On Mon, Dec 14, 2015 at 12:42:58PM -0600, Nishanth Menon wrote:
>
> > >> Enable PMIC for beaglebone similar to commit 7a5c6065669c ("ARM:
> > >> OMAP2+: omap2plus_defconfig: Add tps65217 support") - this allows
> > >> multi_v7_defconfig to boot up on older beaglebone platforms.
> > >
> > > A similar one -
> > >
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384289.html
> > >
> > > your v1 was earlier than the above, so mine should > /dev/null.
> >
> > If you'd like to, please reply back on original patch dropping your
> > patch.. or if queued, I can drop mine (I dont see it on linux-next
> > yet).
>
> That patch didn't get a reply at all, hence assuming that it won't be
> picked & don't want to create a noise on that silent thread ;), but if
> it gets applied, i will fight against my patch :)
As mentioned in the earlier reply, don't assume a patch that hasn't been
applied yet won't be -- please follow up with a redaction of it if that's what
you want. Since I go through my mail folder in chronological order, I come
across your patch first and will apply it when I get to it.
Anyway, not a big deal since the contents is the same.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/3] ARM: multi_v7_defconfig: Enable generic SoC internal OMAP regulators
On Mon, Dec 14, 2015 at 12:43:00PM -0600, Nishanth Menon wrote: > ABB and PBIAS are internal LDO control regulators that are needed for > maintaining proper functionality of OMAP architecture SoCs. Enable the > same. PBIAS is already enabled, so just enable ABB regulator as well. > > Signed-off-by: Nishanth Menon Applied, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] bus: uniphier-system-bus: add UniPhier System Bus driver
On Wed, Dec 09, 2015 at 03:52:59PM +0900, Masahiro Yamada wrote: > The UniPhier System Bus is an external bus that connects on-board > devices to the UniPhier SoC. Each bank (chip select) is dynamically > mapped to the CPU-viewed address base via the bus controller. The > bus controller must be configured before any access to the bus. > > This driver parses the "ranges" property of the System Bus node and > initialized the bus controller. After the bus becomes ready, devices > below it are populated. > > Note: > Each bank can be mapped anywhere in the supported address space; > there is nothing preventing us from assigning bank 0 on 0x4200, > 0x4300, or anywhere as long as such region is not used by others. > So, the "ranges" is just one possible software configuration, which > does not seem to fit in device tree because device tree is a hardware > description language. However, of_translate_address() requires > "ranges" in every bus node between CPUs and device mapped on the CPU > address space. In other words, "ranges" properties must be statically > defined in device tree. After some discussion, I decided the dynamic > address reassignment by the driver is too bothersome. Instead, the > device tree should provide a reasonable translation setup that the OS > can rely on. > > Signed-off-by: Masahiro Yamada > Acked-by: Rob Herring > Acked-by: Arnd Bergmann Thanks, applied to next/drivers. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] vfio: Include No-IOMMU mode
There is really no way to safely give a user full access to a DMA
capable device without an IOMMU to protect the host system. There is
also no way to provide DMA translation, for use cases such as device
assignment to virtual machines. However, there are still those users
that want userspace drivers even under those conditions. The UIO
driver exists for this use case, but does not provide the degree of
device access and programming that VFIO has. In an effort to avoid
code duplication, this introduces a No-IOMMU mode for VFIO.
This mode requires building VFIO with CONFIG_VFIO_NOIOMMU and enabling
the "enable_unsafe_noiommu_mode" option on the vfio driver. This
should make it very clear that this mode is not safe. Additionally,
CAP_SYS_RAWIO privileges are necessary to work with groups and
containers using this mode. Groups making use of this support are
named /dev/vfio/noiommu-$GROUP and can only make use of the special
VFIO_NOIOMMU_IOMMU for the container. Use of this mode, specifically
binding a device without a native IOMMU group to a VFIO bus driver
will taint the kernel and should therefore not be considered
supported. This patch includes no-iommu support for the vfio-pci bus
driver only.
Signed-off-by: Alex Williamson
Acked-by: Michael S. Tsirkin
---
v4: Fix build without CONFIG_VFIO_NOIOMMU (oops). Also avoid local
noiommu variable in vfio_create_group() to avoid scope confusion
with global of the same name.
drivers/vfio/Kconfig| 15
drivers/vfio/pci/vfio_pci.c |8 +-
drivers/vfio/vfio.c | 184 ++-
include/linux/vfio.h|3 +
include/uapi/linux/vfio.h |7 ++
5 files changed, 210 insertions(+), 7 deletions(-)
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 850d86c..da6e2ce 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -31,6 +31,21 @@ menuconfig VFIO
If you don't know what to do here, say N.
+menuconfig VFIO_NOIOMMU
+ bool "VFIO No-IOMMU support"
+ depends on VFIO
+ help
+ VFIO is built on the ability to isolate devices using the IOMMU.
+ Only with an IOMMU can userspace access to DMA capable devices be
+ considered secure. VFIO No-IOMMU mode enables IOMMU groups for
+ devices without IOMMU backing for the purpose of re-using the VFIO
+ infrastructure in a non-secure mode. Use of this mode will result
+ in an unsupportable kernel and will therefore taint the kernel.
+ Device assignment to virtual machines is also not possible with
+ this mode since there is no IOMMU to provide DMA translation.
+
+ If you don't know what to do here, say N.
+
source "drivers/vfio/pci/Kconfig"
source "drivers/vfio/platform/Kconfig"
source "virt/lib/Kconfig"
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 56bf6db..2760a7b 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -940,13 +940,13 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL)
return -EINVAL;
- group = iommu_group_get(>dev);
+ group = vfio_iommu_group_get(>dev);
if (!group)
return -EINVAL;
vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
if (!vdev) {
- iommu_group_put(group);
+ vfio_iommu_group_put(group, >dev);
return -ENOMEM;
}
@@ -957,7 +957,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
ret = vfio_add_group_dev(>dev, _pci_ops, vdev);
if (ret) {
- iommu_group_put(group);
+ vfio_iommu_group_put(group, >dev);
kfree(vdev);
return ret;
}
@@ -993,7 +993,7 @@ static void vfio_pci_remove(struct pci_dev *pdev)
if (!vdev)
return;
- iommu_group_put(pdev->dev.iommu_group);
+ vfio_iommu_group_put(pdev->dev.iommu_group, >dev);
kfree(vdev);
if (vfio_pci_is_vga(pdev)) {
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 6070b79..82f25cc 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -62,6 +62,7 @@ struct vfio_container {
struct rw_semaphore group_lock;
struct vfio_iommu_driver*iommu_driver;
void*iommu_data;
+ boolnoiommu;
};
struct vfio_unbound_dev {
@@ -84,6 +85,7 @@ struct vfio_group {
struct list_headunbound_list;
struct mutexunbound_lock;
atomic_topened;
+ boolnoiommu;
};
struct vfio_device {
@@ -95,6 +97,128 @@ struct vfio_device {
void*device_data;
};
+#ifdef CONFIG_VFIO_NOIOMMU
+static bool
Re: [PATCHV3 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks
On Tue, Dec 22, 2015 at 3:13 AM, Borislav Petkov wrote: >> +#define COPY_MCHECK_ERRBIT BIT(63) > > What happened to the landing pads Andy was talking about? They sound > like cleaner design than that bit 63... I interpreted that comment as "stop playing with %rax in the fault handler ... just change the IP to point the the .fixup location" ... the target of the fixup being the "landing pad". Right now this function has only one set of fault fixups (for machine checks). When I tackle copy_from_user() it will sprout a second set for page faults, and then will look a bit more like Andy's dual landing pad example. I still need an indicator to the caller which type of fault happened since their actions will be different. So BIT(63) lives on ... but is now set in the .fixup section rather than in the machine check code. I'll move the function and #defines as you suggest - we don't need new files for these. Also will fix the assembly code. [In my defense that load immediate 0x8000 and 'or' was what gcc -O2 generates from a simple bit of C code to set bit 63 ... perhaps it is faster, or perhaps gcc is on drugs. In this case code compactness wins over possible speed difference]. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] watchdog: Separate and maintain variables based on variable lifetime
On 12/22/2015 11:28 AM, Damien Riegel wrote: On Tue, Dec 22, 2015 at 08:22:40AM -0800, Guenter Roeck wrote: On 12/22/2015 08:09 AM, Damien Riegel wrote: On Mon, Dec 21, 2015 at 05:10:58PM -0800, Guenter Roeck wrote: On 12/21/2015 09:28 AM, Damien Riegel wrote: On Sun, Dec 20, 2015 at 01:05:00PM -0800, Guenter Roeck wrote: All variables required by the watchdog core to manage a watchdog are currently stored in struct watchdog_device. The lifetime of those variables is determined by the watchdog driver. However, the lifetime of variables used by the watchdog core differs from the lifetime of struct watchdog_device. To remedy this situation, watchdog drivers can implement ref and unref callbacks, to be used by the watchdog core to lock struct watchdog_device in memory. While this solves the immediate problem, it depends on watchdog drivers to actually implement the ref/unref callbacks. This is error prone, often not implemented in the first place, or not implemented correctly. To solve the problem without requiring driver support, split the variables in struct watchdog_device into two data structures - one for variables associated with the watchdog driver, one for variables associated with the watchdog core. With this approach, the watchdog core can keep track of its variable lifetime and no longer depends on ref/unref callbacks in the driver. As a side effect, some of the variables originally in struct watchdog_driver are now private to the watchdog core and no longer visible in watchdog drivers. The 'ref' and 'unref' callbacks in struct watchdog_driver are no longer used and marked as deprecated. Two comments below. It's great to see that unbinding a driver no longer triggers a kernel panic. It should not have caused a panic to start with, but the ref/unref functions for the most part were either not or wrongly implemented. Not really surprising - it took me a while to understand the problem. I tested on a driver which did not implement ref/unref. When ping is called, it tries to dereference a freed 'struct watchdog_device' in watchdog_get_drvdata, leading to a panic. Yes, that will happen. Problem here is that the driver is buggy - pretty much all drivers which dynamically allocate struct watchdog_device have this problem. This is the ultimate reason for coming up with this patch. [ ... ] /* + * struct _watchdog_device - watchdog core internal data Think it should be /**. Anyway, I find it confusing to have both _watchdog_device and watchdog_device, but I can't think of a better name right now. I renamed the data structure to watchdog_data and moved it into watchdog_dev.c since it is only used there. No '**', though, because it is not a published API, but just an internal data structure. I also renamed the matching variable name to 'wd_data' (from '_wdd'). Okay. Also, why didn't you use the explicit type for 'wdd_data' in 'struct watchdog_device' instead of a void*? This is to hide the data type, since the structure is not exported to drivers. I could pre-declare the structure with 'struct watchdog_data;', but then I'd have to use a different structure name (watchdog_cdev_data, maybe, or watchdog_core_data) to make it less generic. Any opinion ? Would that be better / preferred ? I am 50/50 about it. My personal preference would be to be explicit. That makes code nagivation easier and it might help the compiler catch some mistakes. Plus, as you moved the structure definition in watchdog_dev.c, it is very clear that drivers aren't supposed to use it. Ok, makes sense. I'll do that. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization
On 12/22/2015 11:13 AM, Laura Abbott wrote: >> 3. Zero at free, *don't* Zero at alloc (when __GFP_ZERO) >> (what I'm suggesting, possibly less perf impact vs. #2) > > poisoning with non-zero memory makes it easier to determine that the error > came from accessing the sanitized memory vs. some other case. I don't think > the feature would be as strong if the memory was only zeroed vs. some other > data value. How does that scenario work? Your patch description says: > + Use-after-free bugs for structures containing > + pointers can also be detected as dereferencing the sanitized pointer > + will generate an access violation. In the case that we wrote all zeros, we'd be accessing userspace at a known place that we don't generally allow memory to be mapped anyway. Could you elaborate on a scenario where zeros are weaker than a random poison value? In any case (if a poison value is superior to 0's), it's a balance between performance vs. the likelihood of the poisoned value being tripped over. I think the performance impact of this feature is going to be *the* major thing that keeps folks from using it in practice. I'm trying to suggest a way that you _might_ preserve some performance, and get more folks to use it. 1. Keep information from leaking (doesn't matter which value we write) 2. Detect use-after-free bugs (0's are less likely to be detected???) 3. Preserve performance (0's are likely to preserve more performance) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header
This patch consolidates "arch/x86/kernel/cpu/perf_event_amd_iommu.h" and "drivers/iommu/amd_iommu_proto.h", which contain duplicate function declarations, into "include/linux/perf/perf_event_amd_iommu.h" Signed-off-by: Suravee Suthikulpanit --- arch/x86/kernel/cpu/perf_event_amd_iommu.c | 2 +- arch/x86/kernel/cpu/perf_event_amd_iommu.h | 40 -- drivers/iommu/amd_iommu_init.c | 2 ++ drivers/iommu/amd_iommu_proto.h| 7 -- include/linux/perf/perf_event_amd_iommu.h | 40 ++ 5 files changed, 43 insertions(+), 48 deletions(-) delete mode 100644 arch/x86/kernel/cpu/perf_event_amd_iommu.h create mode 100644 include/linux/perf/perf_event_amd_iommu.h diff --git a/arch/x86/kernel/cpu/perf_event_amd_iommu.c b/arch/x86/kernel/cpu/perf_event_amd_iommu.c index 86f8259..1192f1d 100644 --- a/arch/x86/kernel/cpu/perf_event_amd_iommu.c +++ b/arch/x86/kernel/cpu/perf_event_amd_iommu.c @@ -12,12 +12,12 @@ */ #include +#include #include #include #include #include "perf_event.h" -#include "perf_event_amd_iommu.h" #define COUNTER_SHIFT 16 diff --git a/arch/x86/kernel/cpu/perf_event_amd_iommu.h b/arch/x86/kernel/cpu/perf_event_amd_iommu.h deleted file mode 100644 index 845d173..000 --- a/arch/x86/kernel/cpu/perf_event_amd_iommu.h +++ /dev/null @@ -1,40 +0,0 @@ -/* - * Copyright (C) 2013 Advanced Micro Devices, Inc. - * - * Author: Steven Kinney - * Author: Suravee Suthikulpanit - * - * 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 - * published by the Free Software Foundation. - */ - -#ifndef _PERF_EVENT_AMD_IOMMU_H_ -#define _PERF_EVENT_AMD_IOMMU_H_ - -/* iommu pc mmio region register indexes */ -#define IOMMU_PC_COUNTER_REG 0x00 -#define IOMMU_PC_COUNTER_SRC_REG 0x08 -#define IOMMU_PC_PASID_MATCH_REG 0x10 -#define IOMMU_PC_DOMID_MATCH_REG 0x18 -#define IOMMU_PC_DEVID_MATCH_REG 0x20 -#define IOMMU_PC_COUNTER_REPORT_REG0x28 - -/* maximun specified bank/counters */ -#define PC_MAX_SPEC_BNKS 64 -#define PC_MAX_SPEC_CNTRS 16 - -/* iommu pc reg masks*/ -#define IOMMU_BASE_DEVID 0x - -/* amd_iommu_init.c external support functions */ -extern bool amd_iommu_pc_supported(void); - -extern u8 amd_iommu_pc_get_max_banks(u16 devid); - -extern u8 amd_iommu_pc_get_max_counters(u16 devid); - -extern int amd_iommu_pc_get_set_reg_val(u16 devid, u8 bank, u8 cntr, - u8 fxn, u64 *value, bool is_write); - -#endif /*_PERF_EVENT_AMD_IOMMU_H_*/ diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index 013bdff..b6d684c 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -27,6 +27,8 @@ #include #include #include +#include + #include #include #include diff --git a/drivers/iommu/amd_iommu_proto.h b/drivers/iommu/amd_iommu_proto.h index 0bd9eb3..ac2da91 100644 --- a/drivers/iommu/amd_iommu_proto.h +++ b/drivers/iommu/amd_iommu_proto.h @@ -55,13 +55,6 @@ extern int amd_iommu_domain_set_gcr3(struct iommu_domain *dom, int pasid, extern int amd_iommu_domain_clear_gcr3(struct iommu_domain *dom, int pasid); extern struct iommu_domain *amd_iommu_get_v2_domain(struct pci_dev *pdev); -/* IOMMU Performance Counter functions */ -extern bool amd_iommu_pc_supported(void); -extern u8 amd_iommu_pc_get_max_banks(u16 devid); -extern u8 amd_iommu_pc_get_max_counters(u16 devid); -extern int amd_iommu_pc_get_set_reg_val(u16 devid, u8 bank, u8 cntr, u8 fxn, - u64 *value, bool is_write); - #ifdef CONFIG_IRQ_REMAP extern int amd_iommu_create_irq_domain(struct amd_iommu *iommu); #else diff --git a/include/linux/perf/perf_event_amd_iommu.h b/include/linux/perf/perf_event_amd_iommu.h new file mode 100644 index 000..845d173 --- /dev/null +++ b/include/linux/perf/perf_event_amd_iommu.h @@ -0,0 +1,40 @@ +/* + * Copyright (C) 2013 Advanced Micro Devices, Inc. + * + * Author: Steven Kinney + * Author: Suravee Suthikulpanit + * + * 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 + * published by the Free Software Foundation. + */ + +#ifndef _PERF_EVENT_AMD_IOMMU_H_ +#define _PERF_EVENT_AMD_IOMMU_H_ + +/* iommu pc mmio region register indexes */ +#define IOMMU_PC_COUNTER_REG 0x00 +#define IOMMU_PC_COUNTER_SRC_REG 0x08 +#define IOMMU_PC_PASID_MATCH_REG 0x10 +#define IOMMU_PC_DOMID_MATCH_REG 0x18 +#define IOMMU_PC_DEVID_MATCH_REG 0x20 +#define IOMMU_PC_COUNTER_REPORT_REG0x28 + +/* maximun specified bank/counters */ +#define PC_MAX_SPEC_BNKS 64 +#define PC_MAX_SPEC_CNTRS
[PATCH 0/6] perf/amd/iommu: Enable multi-IOMMU support
This patch series modifies the existing perf_event_amd_iommu driver to support systems with multiple IOMMUs. It introduces new AMD IOMMU APIs, which will are used by the AMD IOMMU Perf driver to access performance counters in multiple IOMMUs. In addition, this series should also fix current AMD IOMMU PMU driver initialization issue in some existing CZ platform. Suravee Suthikulpanit (6): perf/amd/iommu: Consolidate and move perf_event_amd_iommu header perf/amd/iommu: Modify functions to query max banks and counters iommu/amd: Introduce amd_iommu_get_num_iommus() perf/amd/iommu: Introduce data structure for tracking prev count. perf/amd/iommu: Introduce get_iommu_bnk_cnt_evt_idx perf/amd/iommu: Enable support for multiple IOMMUs arch/x86/kernel/cpu/perf_event_amd_iommu.c | 145 +++-- arch/x86/kernel/cpu/perf_event_amd_iommu.h | 40 drivers/iommu/amd_iommu_init.c | 125 + drivers/iommu/amd_iommu_proto.h| 7 -- include/linux/perf/perf_event_amd_iommu.h | 43 + 5 files changed, 248 insertions(+), 112 deletions(-) delete mode 100644 arch/x86/kernel/cpu/perf_event_amd_iommu.h create mode 100644 include/linux/perf/perf_event_amd_iommu.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] perf/amd/iommu: Introduce data structure for tracking prev count.
To enable AMD IOMMU PMU to support multiple IOMMUs, this patch introduces
a new data structure, perf_amd_iommu.prev_cnts, to track previous counts
of IOMMU performance counters in multi-IOMMU environment.
Also, this patch allocates perf_iommu_cnts for internal use
when manages counters.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kernel/cpu/perf_event_amd_iommu.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
index e6d2485..99fcd10 100644
--- a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
+++ b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
@@ -42,6 +42,7 @@ struct perf_amd_iommu {
u64 cntr_assign_mask;
raw_spinlock_t lock;
const struct attribute_group *attr_groups[4];
+ local64_t *prev_cnts;
};
#define format_group attr_groups[0]
@@ -126,6 +127,8 @@ static struct amd_iommu_event_desc
amd_iommu_v2_event_descs[] = {
{ /* end: all zeroes */ },
};
+static u64 *perf_iommu_cnts;
+
/*-
* sysfs cpumask attributes
*-*/
@@ -423,10 +426,14 @@ static __init int _init_events_attrs(struct
perf_amd_iommu *perf_iommu)
static __init void amd_iommu_pc_exit(void)
{
- if (__perf_iommu.events_group != NULL) {
- kfree(__perf_iommu.events_group);
- __perf_iommu.events_group = NULL;
- }
+ kfree(__perf_iommu.events_group);
+ __perf_iommu.events_group = NULL;
+
+ kfree(__perf_iommu.prev_cnts);
+ __perf_iommu.prev_cnts = NULL;
+
+ kfree(perf_iommu_cnts);
+ perf_iommu_cnts = NULL;
}
static __init int _init_perf_amd_iommu(
@@ -456,6 +463,17 @@ static __init int _init_perf_amd_iommu(
perf_iommu->null_group = NULL;
perf_iommu->pmu.attr_groups = perf_iommu->attr_groups;
+ perf_iommu->prev_cnts = kzalloc(sizeof(*perf_iommu->prev_cnts) *
+ (amd_iommu_get_num_iommus() * perf_iommu->max_banks *
+ perf_iommu->max_counters), GFP_KERNEL);
+ if (!perf_iommu->prev_cnts)
+ return -ENOMEM;
+
+ perf_iommu_cnts = kzalloc(sizeof(*perf_iommu_cnts) *
+ amd_iommu_get_num_iommus(), GFP_KERNEL);
+ if (!perf_iommu_cnts)
+ return -ENOMEM;
+
ret = perf_pmu_register(_iommu->pmu, name, -1);
if (ret) {
pr_err("perf: amd_iommu: Failed to initialized.\n");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] perf/amd/iommu: Modify functions to query max banks and counters
Currently, amd_iommu_pc_get_max_[banks|counters]() require devid,
which should not be the case. Also, these don't properly support
multi-IOMMU system.
Current and future AMD systems with IOMMU that support perf counter
would likely contain homogeneous IOMMUs where multiple IOMMUs are
availalbe. So, this patch modifies these function to iterate all IOMMU
to check the max banks and counters reported by the hardware.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kernel/cpu/perf_event_amd_iommu.c | 17 +++--
drivers/iommu/amd_iommu_init.c | 20
include/linux/perf/perf_event_amd_iommu.h | 7 ++-
3 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
index 1192f1d..e6d2485 100644
--- a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
+++ b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
@@ -237,14 +237,6 @@ static int perf_iommu_event_init(struct perf_event *event)
return -EINVAL;
}
- /* integrate with iommu base devid (), assume one iommu */
- perf_iommu->max_banks =
- amd_iommu_pc_get_max_banks(IOMMU_BASE_DEVID);
- perf_iommu->max_counters =
- amd_iommu_pc_get_max_counters(IOMMU_BASE_DEVID);
- if ((perf_iommu->max_banks == 0) || (perf_iommu->max_counters == 0))
- return -EINVAL;
-
/* update the hw_perf_event struct with the iommu config data */
hwc->config = config;
hwc->extra_reg.config = config1;
@@ -455,6 +447,11 @@ static __init int _init_perf_amd_iommu(
if (_init_events_attrs(perf_iommu) != 0)
pr_err("perf: amd_iommu: Only support raw events.\n");
+ perf_iommu->max_banks = amd_iommu_pc_get_max_banks();
+ perf_iommu->max_counters = amd_iommu_pc_get_max_counters();
+ if ((perf_iommu->max_banks == 0) || (perf_iommu->max_counters == 0))
+ return -EINVAL;
+
/* Init null attributes */
perf_iommu->null_group = NULL;
perf_iommu->pmu.attr_groups = perf_iommu->attr_groups;
@@ -465,8 +462,8 @@ static __init int _init_perf_amd_iommu(
amd_iommu_pc_exit();
} else {
pr_info("perf: amd_iommu: Detected. (%d banks, %d
counters/bank)\n",
- amd_iommu_pc_get_max_banks(IOMMU_BASE_DEVID),
- amd_iommu_pc_get_max_counters(IOMMU_BASE_DEVID));
+ amd_iommu_pc_get_max_banks(),
+ amd_iommu_pc_get_max_counters());
}
return ret;
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index b6d684c..275c0f5 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2251,15 +2251,17 @@ EXPORT_SYMBOL(amd_iommu_v2_supported);
*
/
-u8 amd_iommu_pc_get_max_banks(u16 devid)
+u8 amd_iommu_pc_get_max_banks(void)
{
struct amd_iommu *iommu;
u8 ret = 0;
- /* locate the iommu governing the devid */
- iommu = amd_iommu_rlookup_table[devid];
- if (iommu)
+ for_each_iommu(iommu) {
+ if (!iommu->max_banks ||
+ (ret && (iommu->max_banks != ret)))
+ return 0;
ret = iommu->max_banks;
+ }
return ret;
}
@@ -2271,15 +2273,17 @@ bool amd_iommu_pc_supported(void)
}
EXPORT_SYMBOL(amd_iommu_pc_supported);
-u8 amd_iommu_pc_get_max_counters(u16 devid)
+u8 amd_iommu_pc_get_max_counters(void)
{
struct amd_iommu *iommu;
u8 ret = 0;
- /* locate the iommu governing the devid */
- iommu = amd_iommu_rlookup_table[devid];
- if (iommu)
+ for_each_iommu(iommu) {
+ if (!iommu->max_counters ||
+ (ret && (iommu->max_counters != ret)))
+ return 0;
ret = iommu->max_counters;
+ }
return ret;
}
diff --git a/include/linux/perf/perf_event_amd_iommu.h
b/include/linux/perf/perf_event_amd_iommu.h
index 845d173..815eabb 100644
--- a/include/linux/perf/perf_event_amd_iommu.h
+++ b/include/linux/perf/perf_event_amd_iommu.h
@@ -24,15 +24,12 @@
#define PC_MAX_SPEC_BNKS 64
#define PC_MAX_SPEC_CNTRS 16
-/* iommu pc reg masks*/
-#define IOMMU_BASE_DEVID 0x
-
/* amd_iommu_init.c external support functions */
extern bool amd_iommu_pc_supported(void);
-extern u8 amd_iommu_pc_get_max_banks(u16 devid);
+extern u8 amd_iommu_pc_get_max_banks(void);
-extern u8 amd_iommu_pc_get_max_counters(u16 devid);
+extern u8 amd_iommu_pc_get_max_counters(void);
extern int amd_iommu_pc_get_set_reg_val(u16 devid, u8 bank, u8 cntr,
u8 fxn, u64 *value, bool is_write);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe
Re: Linux 3.14.58
On 12/22/2015 11:39 AM, Guillaume Morin wrote: > Jason, > > On 22 Dec 11:02, Jason Baron wrote: >> We've noticed livelocks in shrink_dentry_list() very similar to this >> report on stable 3.14.56: >> http://lkml.iu.edu/hypermail/linux/kernel/1405.3/00470.html >> >> It appears that the patches that introduced this issue came into 3.14.51 >> in August with the same set of patches mentioned in the referenced >> report. We unfortunately haven't narrowed down a reproducer, so I can't >> bisect the issue, but 3.14.50 did not appear to have the issue. >> >> Upstream merge commit - 6f6111e4a73d0f6370eb8be4f8e4523210b6a67d (Pull >> vfs dcache livelock fix from Al Viro) brought in a series to address >> this issue. So that may be needed here as well... > > FWIW I noticed the same thing. The commits listed in > http://www.spinics.net/lists/stable/msg111553.html fixed the problem for me. > > I assume Greg will pick them up soon... > Thanks for the info! -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] perf/amd/iommu: Enable support for multiple IOMMUs
The current amd_iommu_pc_get_set_reg_val() does not support muli-IOMMU
system. This patch replace amd_iommu_pc_get_set_reg_val() with
amd_iommu_pc_set_reg_val() and amd_iommu_pc_[set|get]_cnt_vals().
This implementation makes an assumption that the counters on all IOMMUs
will be programmed the same way (i.e with the same events).
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kernel/cpu/perf_event_amd_iommu.c | 80 +--
drivers/iommu/amd_iommu_init.c | 87 ++
include/linux/perf/perf_event_amd_iommu.h | 8 ++-
3 files changed, 136 insertions(+), 39 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
index 8af7149..9c60eb3 100644
--- a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
+++ b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
@@ -264,44 +264,46 @@ static void perf_iommu_enable_event(struct perf_event *ev)
u64 reg = 0ULL;
reg = csource;
- amd_iommu_pc_get_set_reg_val(devid,
+ amd_iommu_pc_set_reg_val(devid,
_GET_BANK(ev), _GET_CNTR(ev) ,
-IOMMU_PC_COUNTER_SRC_REG, , true);
+IOMMU_PC_COUNTER_SRC_REG, );
reg = 0ULL | devid | (_GET_DEVID_MASK(ev) << 32);
if (reg)
reg |= (1UL << 31);
- amd_iommu_pc_get_set_reg_val(devid,
+ amd_iommu_pc_set_reg_val(devid,
_GET_BANK(ev), _GET_CNTR(ev) ,
-IOMMU_PC_DEVID_MATCH_REG, , true);
+IOMMU_PC_DEVID_MATCH_REG, );
reg = 0ULL | _GET_PASID(ev) | (_GET_PASID_MASK(ev) << 32);
if (reg)
reg |= (1UL << 31);
- amd_iommu_pc_get_set_reg_val(devid,
+ amd_iommu_pc_set_reg_val(devid,
_GET_BANK(ev), _GET_CNTR(ev) ,
-IOMMU_PC_PASID_MATCH_REG, , true);
+IOMMU_PC_PASID_MATCH_REG, );
reg = 0ULL | _GET_DOMID(ev) | (_GET_DOMID_MASK(ev) << 32);
if (reg)
reg |= (1UL << 31);
- amd_iommu_pc_get_set_reg_val(devid,
+ amd_iommu_pc_set_reg_val(devid,
_GET_BANK(ev), _GET_CNTR(ev) ,
-IOMMU_PC_DOMID_MATCH_REG, , true);
+IOMMU_PC_DOMID_MATCH_REG, );
}
static void perf_iommu_disable_event(struct perf_event *event)
{
u64 reg = 0ULL;
- amd_iommu_pc_get_set_reg_val(_GET_DEVID(event),
+ amd_iommu_pc_set_reg_val(_GET_DEVID(event),
_GET_BANK(event), _GET_CNTR(event),
- IOMMU_PC_COUNTER_SRC_REG, , true);
+ IOMMU_PC_COUNTER_SRC_REG, );
}
static void perf_iommu_start(struct perf_event *event, int flags)
{
struct hw_perf_event *hwc = >hw;
+ struct perf_amd_iommu *perf_iommu =
+ container_of(event->pmu, struct perf_amd_iommu, pmu);
pr_debug("perf: amd_iommu:perf_iommu_start\n");
if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
@@ -311,10 +313,19 @@ static void perf_iommu_start(struct perf_event *event,
int flags)
hwc->state = 0;
if (flags & PERF_EF_RELOAD) {
- u64 prev_raw_count = local64_read(>prev_count);
- amd_iommu_pc_get_set_reg_val(_GET_DEVID(event),
- _GET_BANK(event), _GET_CNTR(event),
- IOMMU_PC_COUNTER_REG, _raw_count, true);
+ int i;
+
+ for (i = 0; i < amd_iommu_get_num_iommus(); i++) {
+ int index = get_iommu_bnk_cnt_evt_idx(perf_iommu, i,
+ _GET_BANK(event), _GET_CNTR(event));
+
+ perf_iommu_cnts[i] = local64_read(
+ _iommu->prev_cnts[index]);
+ }
+
+ amd_iommu_pc_set_cnt_vals(_GET_BANK(event), _GET_CNTR(event),
+ amd_iommu_get_num_iommus(),
+ perf_iommu_cnts);
}
perf_iommu_enable_event(event);
@@ -324,29 +335,42 @@ static void perf_iommu_start(struct perf_event *event,
int flags)
static void perf_iommu_read(struct perf_event *event)
{
- u64 count = 0ULL;
+ int i;
u64 prev_raw_count = 0ULL;
u64 delta = 0ULL;
struct hw_perf_event *hwc = >hw;
+ struct perf_amd_iommu *perf_iommu =
+ container_of(event->pmu, struct perf_amd_iommu, pmu);
+
pr_debug("perf: amd_iommu:perf_iommu_read\n");
- amd_iommu_pc_get_set_reg_val(_GET_DEVID(event),
- _GET_BANK(event), _GET_CNTR(event),
- IOMMU_PC_COUNTER_REG, , false);
+ if (amd_iommu_pc_get_cnt_vals(_GET_BANK(event), _GET_CNTR(event),
+ amd_iommu_get_num_iommus(),
+
[PATCH 5/6] perf/amd/iommu: Introduce get_iommu_bnk_cnt_evt_idx
Introduce a helper function to calculate bit-index for assigning
performance counter assignment.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kernel/cpu/perf_event_amd_iommu.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
index 99fcd10..8af7149 100644
--- a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
+++ b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
@@ -153,18 +153,28 @@ static struct attribute_group amd_iommu_cpumask_group = {
/*-*/
+static inline
+int get_iommu_bnk_cnt_evt_idx(struct perf_amd_iommu *perf_iommu,
+ int iommu_index, int bank_index,
+ int cntr_index)
+{
+ int cntrs_per_iommu = perf_iommu->max_banks * perf_iommu->max_counters;
+ int index = (perf_iommu->max_counters * bank_index) + cntr_index;
+
+ return (cntrs_per_iommu * iommu_index) + index;
+}
+
static int get_next_avail_iommu_bnk_cntr(struct perf_amd_iommu *perf_iommu)
{
unsigned long flags;
int shift, bank, cntr, retval;
- int max_banks = perf_iommu->max_banks;
- int max_cntrs = perf_iommu->max_counters;
raw_spin_lock_irqsave(_iommu->lock, flags);
- for (bank = 0, shift = 0; bank < max_banks; bank++) {
- for (cntr = 0; cntr < max_cntrs; cntr++) {
- shift = bank + (bank*3) + cntr;
+ for (bank = 0, shift = 0; bank < perf_iommu->max_banks; bank++) {
+ for (cntr = 0; cntr < perf_iommu->max_counters; cntr++) {
+ shift = get_iommu_bnk_cnt_evt_idx(perf_iommu,
+ 0, bank, cntr);
if (perf_iommu->cntr_assign_mask & (1ULL
[PATCH 3/6] iommu/amd: Introduce amd_iommu_get_num_iommus()
This patch introduces amd_iommu_get_num_iommus(). Initially, this is
intended to be used by Perf AMD IOMMU driver.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd_iommu_init.c| 16
include/linux/perf/perf_event_amd_iommu.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 275c0f5..9c62613 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2244,6 +2244,22 @@ bool amd_iommu_v2_supported(void)
}
EXPORT_SYMBOL(amd_iommu_v2_supported);
+static int amd_iommu_cnt;
+
+int amd_iommu_get_num_iommus(void)
+{
+ struct amd_iommu *iommu;
+
+ if (amd_iommu_cnt)
+ return amd_iommu_cnt;
+
+ for_each_iommu(iommu)
+ amd_iommu_cnt++;
+
+ return amd_iommu_cnt;
+}
+EXPORT_SYMBOL(amd_iommu_get_num_iommus);
+
/
*
* IOMMU EFR Performance Counter support functionality. This code allows
diff --git a/include/linux/perf/perf_event_amd_iommu.h
b/include/linux/perf/perf_event_amd_iommu.h
index 815eabb..cb820c2 100644
--- a/include/linux/perf/perf_event_amd_iommu.h
+++ b/include/linux/perf/perf_event_amd_iommu.h
@@ -25,6 +25,8 @@
#define PC_MAX_SPEC_CNTRS 16
/* amd_iommu_init.c external support functions */
+extern int amd_iommu_get_num_iommus(void);
+
extern bool amd_iommu_pc_supported(void);
extern u8 amd_iommu_pc_get_max_banks(void);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trace.h: correct typo in code comment
On Tue, 22 Dec 2015 09:44:33 -0500
Chuyu Hu wrote:
Thanks, I'll add this. But it's not a typo. It's just outdated.
I'll fix up the subject too.
-- Steve
> Signed-off-by: Chuyu Hu
> ---
> kernel/trace/trace.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 919d9d0..c71d54b 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -363,8 +363,8 @@ struct trace_option_dentry {
> * @name: the name chosen to select it on the available_tracers file
> * @init: called when one switches to this tracer (echo name >
> current_tracer)
> * @reset: called when one switches to another tracer
> - * @start: called when tracing is unpaused (echo 1 > tracing_enabled)
> - * @stop: called when tracing is paused (echo 0 > tracing_enabled)
> + * @start: called when tracing is unpaused (echo 1 > tracing_on)
> + * @stop: called when tracing is paused (echo 0 > tracing_on)
> * @update_thresh: called when tracing_thresh is updated
> * @open: called when the trace file is opened
> * @pipe_open: called when the trace_pipe file is opened
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] watchdog: Separate and maintain variables based on variable lifetime
On Tue, Dec 22, 2015 at 08:22:40AM -0800, Guenter Roeck wrote: > On 12/22/2015 08:09 AM, Damien Riegel wrote: > >On Mon, Dec 21, 2015 at 05:10:58PM -0800, Guenter Roeck wrote: > >>On 12/21/2015 09:28 AM, Damien Riegel wrote: > >>>On Sun, Dec 20, 2015 at 01:05:00PM -0800, Guenter Roeck wrote: > All variables required by the watchdog core to manage a watchdog are > currently stored in struct watchdog_device. The lifetime of those > variables is determined by the watchdog driver. However, the lifetime > of variables used by the watchdog core differs from the lifetime of > struct watchdog_device. To remedy this situation, watchdog drivers > can implement ref and unref callbacks, to be used by the watchdog > core to lock struct watchdog_device in memory. > > While this solves the immediate problem, it depends on watchdog drivers > to actually implement the ref/unref callbacks. This is error prone, > often not implemented in the first place, or not implemented correctly. > > To solve the problem without requiring driver support, split the variables > in struct watchdog_device into two data structures - one for variables > associated with the watchdog driver, one for variables associated with > the watchdog core. With this approach, the watchdog core can keep track > of its variable lifetime and no longer depends on ref/unref callbacks > in the driver. As a side effect, some of the variables originally in > struct watchdog_driver are now private to the watchdog core and no longer > visible in watchdog drivers. > > The 'ref' and 'unref' callbacks in struct watchdog_driver are no longer > used and marked as deprecated. > >>> > >>>Two comments below. It's great to see that unbinding a driver no longer > >>>triggers a kernel panic. > >>> > >>It should not have caused a panic to start with, but the ref/unref functions > >>for the most part were either not or wrongly implemented. Not really > >>surprising - it took me a while to understand the problem. > > > >I tested on a driver which did not implement ref/unref. When ping is > >called, it tries to dereference a freed 'struct watchdog_device' in > >watchdog_get_drvdata, leading to a panic. > > > Yes, that will happen. Problem here is that the driver is buggy - > pretty much all drivers which dynamically allocate struct watchdog_device > have this problem. > > This is the ultimate reason for coming up with this patch. > > >> > >>[ ... ] > >> > > /* > + * struct _watchdog_device - watchdog core internal data > >>> > >>>Think it should be /**. Anyway, I find it confusing to have both > >>>_watchdog_device and watchdog_device, but I can't think of a better > >>>name right now. > >> > >>I renamed the data structure to watchdog_data and moved it into > >>watchdog_dev.c > >>since it is only used there. No '**', though, because it is not a published > >>API, but just an internal data structure. > >> > >>I also renamed the matching variable name to 'wd_data' (from '_wdd'). > > > >Okay. Also, why didn't you use the explicit type for 'wdd_data' in > >'struct watchdog_device' instead of a void*? > > > > This is to hide the data type, since the structure is not exported > to drivers. > > I could pre-declare the structure with 'struct watchdog_data;', but > then I'd have to use a different structure name (watchdog_cdev_data, > maybe, or watchdog_core_data) to make it less generic. Any opinion ? > Would that be better / preferred ? I am 50/50 about it. My personal preference would be to be explicit. That makes code nagivation easier and it might help the compiler catch some mistakes. Plus, as you moved the structure definition in watchdog_dev.c, it is very clear that drivers aren't supposed to use it. Thanks, Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the rtc tree
Hi Sasha, On 18/12/2015 at 17:43:41 +0100, Alexandre Belloni wrote : > > > Sasha, I think I prefer having 32 bit platforms fail on the 21st of > > > January 11761191 rather than adding more uses of do_div in the function. > > > I'll have a look at the performance impact on 32 bit platforms. > > > > I'm really fine with just adding a WARN_ON() and aborting if it's the year > > 11761191 :) > > > > One simple way to solve it for 64bit platforms is to define days as > unsigned long. Maybe throw a comment that it will fail for 32bit > platforms in January 11761191 ;). > I did that: http://git.kernel.org/cgit/linux/kernel/git/abelloni/linux.git/commit/?h=rtc-next=0d3da1806b985f1100615c2c09033b404941b63e Unless you disagree, that is what I'm planning to send to Linus. I wish you a happy end of year. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] serial: rewrite pxa2xx-uart to use 8250_core
Sergei Ianovich writes: > On Sun, 2015-12-20 at 00:12 +0100, Robert Jarzmik wrote: >> Sergei Ianovich writes: >> >> > On Sat, 2015-12-19 at 20:31 +0100, Robert Jarzmik wrote: >> > I understand that people are afraid of taking this patch. If it >> > starts >> > causing troubles at runtime, it will be difficult to diagnose. There >> > will be no console for most people. So it is probably good idea to >> > fail >> > at boot time. >> If it's about something already written in a mailing >> list, please point me to it so that it can help me think about it. > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/2167 > 73.html > > I can explain why I think so. Greg acked the patch, but hasn't merged it > since then. He has good reasons for this most probably. Russell's > comment pointed by the link seems to be the reason. > I think the problem raised by Russell could be addressed. My best guess > is compile time error, despite your comment above. I re-read carefully Russell's answer in [1]. What Russell asked is that for a period of time, the old pxa serial code and the new will be in the kernel, so that maintainers have the option to switch over to the old drivers/tty/serial/pxa.c if the new 8250 based version breaks their userspace getty. Then, once the transition is done, and that for a period (let's say 1 year) no maintainer had complained while its defconfig was switched over to the new 8520 version, then and only then you will remove drivers/tty/serial/pxa.c. > I have one more plan. For transition period, we can introduce a > temporary Kconfig option SERIAL_8250_PXA_OFF, and fail at build time if > neither SERIAL_8250_PXA nor SERIAL_8250_PXA_OFF is set. This way all > interested parties will be notified of this driver update. No, I'd like to stick with Russell's original plan : - phase 1: both SERIAL_8250_PXA and SERIAL_PXA exist in KConfig both are selectable This lasts one year or something like that - phase 2: remove SERIAL_PXA from KConfig and drivers/tty/serial/pxa.c This means a different patch from the one acked by Greg, and a new serie of acks. The diffstat will be way worse (as you won't have the -970 for pxa.c), but in the end it will end up on that -970. That sounds like a good transition plan to me. Cheers. -- Robert [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/216773.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/5] mmc: shdci-bcm2835: add verify for 32-bit back-to-back workaround
Hi Stefan,
On 15-12-22 07:55 AM, Stefan Wahren wrote:
Hi Scott,
Am 07.11.2014 um 19:31 schrieb Scott Branden:
On 14-11-05 09:01 PM, Stephen Warren wrote:
On 11/05/2014 12:00 AM, Scott Branden wrote:
On 14-11-04 08:59 PM, Stephen Warren wrote:
On 10/30/2014 12:36 AM, Scott Branden wrote:
Add a verify option to driver to print out an error message if a
potential back to back write could cause a clock domain issue.
index f8c450a..11af27f 100644
+#ifdef CONFIG_MMC_SDHCI_BCM2835_VERIFY_WORKAROUND
+struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+struct bcm2835_sdhci_host *bcm2835_host = pltfm_host->priv;
+
+if (bcm2835_host->previous_reg == reg) {
+if ((reg != SDHCI_HOST_CONTROL)
+&& (reg != SDHCI_CLOCK_CONTROL)) {
The comment in patch 3 says the problem doesn't apply to the data
register. Why does this check for these two registers rather than data?
This Verify workaround patch still a work in progress. I'm still
getting more info from the silicon designers on the back-to-back
register writes that are affect. The spew of 0x20 or 0x28 or 0x2c
register writes are all ok locations that don't need to be worked
around. This patch needs to be corrected with the proper register rules
still.
Thanks for testing. Yes, I have work to do on the verify patch above
still.
do you still have plans to submit a V3 of this patch series?
No, I do not have plans to submit a V3 of this patch series.
I submitted this patch as RPI has a similar controller to the SoCs I am
familiar with as well as needing similar work arounds You can take
over the patchset. Or, try and get the sdhci-iproc.c driver going on
RPI. The sdhci-iproc is the production driver we use on a variety of
SoCs and support and test this driver.
I attached an improved version of this patch which avoids a possible
endless loop caused by the dev_err call. So only the first occurence
of a specific register will be logged.
OK, but is this really necessary? If veryify workaround ever prints
anything then the driver workarounds aren't doing what it is supposed to
anyway?
Regards
Stefan
---8<---
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1526b8a..7b0990f 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -306,6 +306,15 @@ config MMC_SDHCI_BCM2835
If unsure, say N.
+config MMC_SDHCI_BCM2835_VERIFY_WORKAROUND
+ bool "Verify BCM2835 workaround does not do back to back writes"
+ depends on MMC_SDHCI_BCM2835
+ default y
+ help
+ This enables code that verifies the bcm2835 workaround.
+ The verification code checks that back to back writes to the same
+ register do not occur.
+
config MMC_SDHCI_F_SDH30
tristate "SDHCI support for Fujitsu Semiconductor F_SDH30"
depends on MMC_SDHCI_PLTFM
diff --git a/drivers/mmc/host/sdhci-bcm2835.c
b/drivers/mmc/host/sdhci-bcm2835.c
index 01ce193d..c1c70df 100644
--- a/drivers/mmc/host/sdhci-bcm2835.c
+++ b/drivers/mmc/host/sdhci-bcm2835.c
@@ -20,15 +20,27 @@
*/
#include
+#include
#include
#include
+#include
#include "sdhci-pltfm.h"
struct bcm2835_sdhci_host {
u32 shadow_cmd;
u32 shadow_blk;
+ int previous_reg;
};
+struct reg_hash {
+ struct hlist_node node;
+ int reg;
+};
+
+#define BCM2835_REG_HT_BITS 4
+
+static DEFINE_HASHTABLE(bcm2835_used_regs, BCM2835_REG_HT_BITS);
+
#define REG_OFFSET_IN_BITS(reg) ((reg) << 3 & 0x18)
static inline u32 bcm2835_sdhci_readl(struct sdhci_host *host, int reg)
@@ -56,8 +68,37 @@ static u8 bcm2835_sdhci_readb(struct sdhci_host
*host, int reg)
}
static inline void bcm2835_sdhci_writel(struct sdhci_host *host,
+ u32 val, int reg)
+{
+ writel(val, host->ioaddr + reg);
+}
+
+static inline void bcm2835_sdhci_writel_verify(struct sdhci_host *host,
u32 val, int reg)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct bcm2835_sdhci_host *bcm2835_host = pltfm_host->priv;
+ struct reg_hash *rh;
+ struct hlist_head *head;
+
+ head = _used_regs[hash_min(reg, BCM2835_REG_HT_BITS)];
+
+ if (bcm2835_host->previous_reg == reg) {
+ if ((reg != SDHCI_HOST_CONTROL) &&
+ (reg != SDHCI_CLOCK_CONTROL) &&
+ (hlist_empty(head))) {
+ rh = kzalloc(sizeof(*rh), GFP_KERNEL);
+ if (WARN_ON(!rh))
+ return;
+
+ rh->reg = reg;
+ hash_add(bcm2835_used_regs, >node, rh->reg);
+ dev_err(mmc_dev(host->mmc), "back-to-back write to
0x%x\n",
+ reg);
+ }
+ }
+ bcm2835_host->previous_reg = reg;
+
writel(val, host->ioaddr + reg);
Re: linux-next: Tree for Dec 22 (mm/memcontrol)
On Tue, 22 Dec 2015 10:15:37 -0800 Randy Dunlap wrote: > On 12/21/15 21:29, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20151221: > > > > on i386 or x86_64: > > when CONFIG_SLOB=y: > > ../mm/memcontrol.c: In function 'memcg_update_kmem_limit': > ../mm/memcontrol.c:2974:3: error: implicit declaration of function > 'memcg_online_kmem' [-Werror=implicit-function-declaration] >ret = memcg_online_kmem(memcg); >^ > ../mm/memcontrol.c: In function 'mem_cgroup_css_alloc': > ../mm/memcontrol.c:4229:2: error: too many arguments to function > 'memcg_propagate_kmem' > error = memcg_propagate_kmem(parent, memcg); > ^ > ../mm/memcontrol.c:2949:12: note: declared here > static int memcg_propagate_kmem(struct mem_cgroup *memcg) > ^ I can't reproduce this. config, please? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization
On 12/22/15 10:37 AM, Mathias Krause wrote: On 22 December 2015 at 18:51, Laura Abbott wrote: [snip] Related to this, have you checked that the sanitization doesn't interfere with the various slab handling schemes, namely RCU related specialties? Not all caches are marked SLAB_DESTROY_BY_RCU, some use call_rcu() instead, implicitly relying on the semantics RCU'ed slabs permit, namely allowing a "use-after-free" access to be legitimate within the RCU grace period. Scrubbing the object during that period would break that assumption. I haven't looked into that. I was working off the assumption that if the regular SLAB debug poisoning worked so would the sanitization. The regular debug poisoning only checks for SLAB_DESTROY_BY_RCU so how does that work then? Maybe it doesn't? ;) How many systems, do you think, are running with enabled DEBUG_SLAB / SLUB_DEBUG in production? Not so many, I'd guess. And the ones running into issues probably just disable DEBUG_SLAB / SLUB_DEBUG. Btw, SLUB not only looks for SLAB_DESTROY_BY_RCU but also excludes "call_rcu slabs" via other mechanisms. As SLUB is the default SLAB allocator for quite some time now, even with enabled SLUB_DEBUG one wouldn't be able to trigger RCU related sanitization issues. I've seen SLUB_DEBUG used in stress testing situations but you're right about production and giving up if there are issues. I'll take a closer look at this. Speaking of RCU, do you have a plan to support RCU'ed slabs as well? My only plan was to get the base support in. I didn't have a plan to support RCU slabs but that's certainly something to be done in the future. "Base support", in my opinion, includes covering the buddy allocator as well. Otherwise this feature is incomplete. Point taken. I'll look at the buddy allocator post-holidays. It was also pointed out I should be giving you full credit for this feature originally. I apologize for not doing that. Thanks for doing the original work and taking the time to review this series. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] pci, pcie-thunder-pem: Add PCIe host driver for ThunderX processors.
On 12/22/2015 02:03 AM, Will Deacon wrote:
On Mon, Dec 21, 2015 at 05:53:42PM -0800, David Daney wrote:
From: David Daney
Some Cavium ThunderX processors require quirky access methods for the
config space of the PCIe bridge. Add a driver to provide these config
space accessor functions. The pci-host-generic driver code is used to
configure the PCI machinery.
Signed-off-by: David Daney
---
.../devicetree/bindings/pci/pcie-thunder-pem.txt | 43
drivers/pci/host/Kconfig | 6 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-thunder-pem.c| 283 +
4 files changed, 333 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
create mode 100644 drivers/pci/host/pcie-thunder-pem.c
diff --git a/Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
b/Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
new file mode 100644
index 000..66824d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
@@ -0,0 +1,43 @@
+* ThunderX PEM PCIe host controller
+
+Firmware-initialized PCIe host controller found on some Cavium
+ThunderX processors.
+
+The properties and their meanings are identical to those described in
+host-heneric-pci.txt except as listed below.
+
+Properties of the host controller node that differ from
+host-heneric-pci.txt:
Consistently odd typo (s/heneric/generic/)!
I'm not sure how I managed to do that. I will fix these and resend.
+
+- compatible : Must be "cavium,pci-host-thunder-pem"
+
+- reg: Two entries: First the configuration space for down
+ stream devices base address and size, as accessed
+ from the parent bus. Second, the register bank of
+ the PEM device PCIe bridge.
+
+Example:
+
+pem2 {
+ compatible = "cavium,pci-host-thunder-pem";
+ device_type = "pci";
+ msi-parent = <>;
+ msi-map = <0 0x1 0x1>;
+ bus-range = <0x8f 0xc7>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+
+ reg = <0x8880 0x8f00 0x0 0x3900>, /* Configuration space */
+ <0x87e0 0xc200 0x0 0x0001>; /* PEM space */
+ ranges = <0x0100 0x00 0x0002 0x88b0 0x0002 0x00
0x0001>, /* I/O */
+<0x0300 0x00 0x1000 0x8890 0x1000 0x0f
0xf000>, /* mem64 */
+<0x4300 0x10 0x 0x88a0 0x 0x10
0x>, /* mem64-pref */
+<0x0300 0x87e0 0xc2f0 0x87e0 0xc200 0x00
0x0010>; /* mem64 PEM BAR4 */
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 0 0 0 24 4>, /* INTA */
+ <0 0 0 2 0 0 0 25 4>, /* INTB */
+ <0 0 0 3 0 0 0 26 4>, /* INTC */
+ <0 0 0 4 0 0 0 27 4>; /* INTD */
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f131ba9..16ed9c3 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -172,4 +172,10 @@ config PCI_HISI
help
Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
+config PCIE_HOST_THUNDER_PEM
+ bool "Cavium Thunder PCIe controller to off-chip devices"
+ depends on PCI_HOST_GENERIC && ARM64
|| COMPILE_TEST ?
(or does the use of writeq get you? If so, maybe COMPILE_TEST && 64BIT)
Yes, we must use writeq in the driver, I will change it to
||(COMPILE_TEST && 64BIT)
Thanks,
David Daney
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization
On 12/22/15 10:19 AM, Dave Hansen wrote: On 12/22/2015 10:08 AM, Christoph Lameter wrote: On Tue, 22 Dec 2015, Dave Hansen wrote: Why would you use zeros? The point is just to clear the information right? The regular poisoning does that. It then allows you to avoid the zeroing at allocation time. Well much of the code is expecting a zeroed object from the allocator and its zeroed at that time. Zeroing makes the object cache hot which is an important performance aspect. Yes, modifying this behavior has a performance impact. It absolutely needs to be evaluated, and I wouldn't want to speculate too much on how good or bad any of the choices are. Just to reiterate, I think we have 3 real choices here: 1. Zero at alloc, only when __GFP_ZERO (behavior today) 2. Poison at free, also Zero at alloc (when __GFP_ZERO) (this patch's proposed behavior, also what current poisoning does, doubles writes) 3. Zero at free, *don't* Zero at alloc (when __GFP_ZERO) (what I'm suggesting, possibly less perf impact vs. #2) poisoning with non-zero memory makes it easier to determine that the error came from accessing the sanitized memory vs. some other case. I don't think the feature would be as strong if the memory was only zeroed vs. some other data value. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 1/9] ARM: EXYNOS: dts: Syscon dependency for v4.5
On Wed, Dec 02, 2015 at 10:39:38AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
>
> The DT changes are needed before switching to syscon-based reboot
> and power off method.
>
> Best regards,
> Krzysztof
>
>
>
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>
> Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
> tags/samsung-dt-syscon-restart-4.5
>
> for you to fetch changes up to 35135f4b95f03be7ebbf31221ce738f1ec0faa02:
>
> ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos5410 (2015-11-20
> 15:58:44 +0900)
Thanks, merged into next/dt.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: at91/dt: sama5d2: add pdmic node
Hi, On 22/12/2015 at 17:26:04 +0800, Songjun Wu wrote : > Add pdmic node.` > > Signed-off-by: Songjun Wu > --- Both patches have been applied and pushed out, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] arm64: dts: uniphier: add PH1-LD10 SoC/board support
On Sat, Nov 28, 2015 at 02:22:31AM +0900, Masahiro Yamada wrote: > This is the first ARMv8 SoC from Socionext Inc. > > Signed-off-by: Masahiro Yamada > --- Thanks, applied. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 3/9] ARM64: EXYNOS: clk: Clock dependency for ARM64 for v4.5
On Wed, Dec 02, 2015 at 10:39:40AM +0900, Krzysztof Kozlowski wrote: > Hi Kukjin, > > Dependency for soc64 changes. > > Best regards, > Krzysztof > > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-clk-arm64-symbols-4.5 > > for you to fetch changes up to 8c2a90ed18a74e8b9cdbba679403faa44d6024fc: > > clk: samsung: Don't build ARMv8 clock drivers on ARMv7 (2015-11-22 19:25:29 > +0900) Hi, Looks like this lacks ack from any of the clock maintainers. Given that EXYNOS_ARM64_COMMON_CLK is not yet introduced, this will cause a breakage in bisectability on some of these platforms as well. I'll hold off on this one for a bit. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5
On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote: > Hi Kukjin, > > Pinctrl for v4.5. > > Best regards, > Krzysztof > > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-drivers-4.5 > > for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36: > > pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 > +0900) Hi, This should either go in through the pinctrl tree, or have an acked/reviewed-by one of the pinctrl maintainers. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 2/9] ARM: EXYNOS: Exynos SoC/mach specific code for v4.5
On Wed, Dec 02, 2015 at 10:39:39AM +0900, Krzysztof Kozlowski wrote: > Hi Kukjin, > > SoC/mach specific code. > > Best regards, > Krzysztof > > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-soc-4.5 > > for you to fetch changes up to 8438aef01d3560549b3a95d247b3a69311fa6f2d: > > ARM: EXYNOS: Remove redundant code from regs-pmu.h (2015-11-20 16:00:47 > +0900) Thanks, merged into next/soc. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 7/9] ARM: EXYNOS: dts: DeviceTree for v4.5
On Wed, Dec 02, 2015 at 10:39:44AM +0900, Krzysztof Kozlowski wrote: > Hi Kukjin, > > A lot of stuff here, mostly cleanups. Description in tag. > > Best regards, > Krzysztof > > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-dt-4.5 > > for you to fetch changes up to 2cf107f1033e0343d45b59d06f16487c8362702f: > > ARM: dts: Unify G2D device node with other devices on exynos4 (2015-11-30 > 17:00:43 +0900) > > > Samsung DeviceTree updates and improvements for 4.5: > 1. Pinctrl for Exynos5410. > 2. eMMC/SDIO minor fixes usage of bindings on Snow and Peach >Chromebooks. > 3. Remove FIMD from Odroid XU3-family because on XU3 it cannot be used >yet and on XU3-Lite and XU4 it is not supported. > 4. Remove deprecated since June 2013 samsung,exynos5-hdmi. > 5. Add support for Pseudo Random Generator on Exynos4 (Trats2 for now). >This depends on new SSS clock. > 6. Add rotator nodes for Exynos4 and Exynos5. > 7. Switch DWC3_1 on Odroid XU3 and XU3-Lite to peripheral mode because >now it cannot be used as OTG. > 8. Cleanup the G2D usage on Exynos4 and add it to a proper domain >in case of Exynos4210. > 9. Put MDMA1 in proper domain on Exynos4210 as well. > 10. Minor cleanups. Given the request to get acks for the pinctrl changes, can you respin this branch without those pieces so we can merge in the rest of it? Thanks! -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 8/9] ARM64: EXYNOS: dts: DeviceTree for ARM64 for v4.5
On Wed, Dec 02, 2015 at 10:39:45AM +0900, Krzysztof Kozlowski wrote: > Hi Kukjin, > > Few changes for Espresso board. > > Best regards, > Krzysztof > > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-dt64-4.5 > > for you to fetch changes up to fb026cb6524744c8bd0f133f4b0d8e2595d04e15: > > arm64: dts: Add reboot node for exynos7 (2015-11-18 22:47:16 +0900) Thanks, merged into next/dt64. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: defconfig: qcom: Enable SSBI drivers
On Tue, Dec 08, 2015 at 05:01:27PM -0600, Andy Gross wrote: > On Tue, Dec 08, 2015 at 04:54:29PM -0600, Andy Gross wrote: > > On Mon, Nov 30, 2015 at 05:08:57PM -0800, Stephen Boyd wrote: > > > Enable some ssbi drivers present on msm8660, msm8960 and apq8064 > > > devices so that we fully exercise the devices present in the dts > > > files. > > > > > > Signed-off-by: Stephen Boyd > > > > Acked-by: Andy Gross > > Arnd, Olof, Kevin, > > Can you guys pick this up. This patch is based off the earlier qcom_defconfig > that was merged through the arm-soc directly. > Sure, but please collect acks and resend since I just get this email in my folder, and not the original patch. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: exynos-adc: fix irqf_oneshot.cocci warnings
On Wed, Dec 02, 2015 at 09:43:10AM +0100, Valentin Rothberg wrote:
> Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
> threaded IRQs without a primary handler need to be requested with
> IRQF_ONESHOT, otherwise the request will fail.
>
> So pass the IRQF_ONESHOT flag in this case.
>
> Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci
>
> Signed-off-by: Fengguang Wu
> Signed-off-by: Valentin Rothberg
> ---
>
> The patch looks fine to me: bad things can happen when interrupts are
> acked before the handler ran.
Hi,
Applied. Thanks.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 9/9] ARM: EXYNOS: Defconfig for v4.5
On Wed, Dec 02, 2015 at 10:39:46AM +0900, Krzysztof Kozlowski wrote: > Hi Kukjin, > > This may conflict with other arm-soc updates... > > Best regards, > Krzysztof > > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-defconfig-4.5 > > for you to fetch changes up to 00a5e81fff2d81c3b1bf45712d3a12c905bc7c66: > > ARM: exynos_defconfig: Set recommended options for systemd (2015-12-01 > 08:28:44 +0900) Merged into next/defconfig. Thanks! -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 6/9] ARM: EXYNOS: clk: Another clock dependency, ARMv7, for v4.5
On Wed, Dec 02, 2015 at 10:39:43AM +0900, Krzysztof Kozlowski wrote: > Hi Kukjin, > > This is also clock dependency. I put it in separate tag in case clock > folks want to pull it also. > > Best regards, > Krzysztof > > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-clk-exynos4-4.5 > > for you to fetch changes up to 94af7a3c310f5877dc6f756179b92f24f89a9b08: > > clk: samsung: exynos4: Add SSS gate clock (2015-11-18 22:02:02 +0900) Again, this should probably go through the clk maintainer (or have an ack). It's just two one-line changes though, so if they're slow to respond we can take it as a fallback. Resend if that's the case. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 4/9] ARM64: EXYNOS: Soc specific code for v4.5
On Wed, Dec 02, 2015 at 10:39:41AM +0900, Krzysztof Kozlowski wrote: > Hi Kukjin, > > ARM64 change touch also defconfig. > > Best regards, > Krzysztof > > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-soc64-4.5 > > for you to fetch changes up to db44c07a3f0b32815bd1f3e731db9e043e57cf9c: > > arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS (2015-11-22 > 19:31:30 +0900) Given that Arnd started splitting out config64 separately, there's a small chance we'll get a conflict here. We can deal with that if needed though. Still, since this branch contains the previous clock branch I can't apply it as it is. Can you respin without that for now? -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] rtc: Replace simple_strtoul by kstrtoul
On 17/12/2015 at 14:11:04 +0100, LABBE Corentin wrote : > The simple_strtoul function is obsolete. > This patch replace it by kstrtoul. > > Since kstrtoul is more strict, it permits to filter some invalid input that > simple_strtoul accept. For example: > echo '1022xxx' > /sys/devices/pnp0/00:03/rtc/rtc0/max_user_freq > cat /sys/devices/pnp0/00:03/rtc/rtc0/max_user_freq > 1022 > > Signed-off-by: LABBE Corentin > --- > drivers/rtc/rtc-sysfs.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/8] Raspberry Pi 2 support.
Alexander Aring writes: > On Mon, Dec 21, 2015 at 03:07:44PM -0800, Eric Anholt wrote: > ... >> > >> > But still getting this panic, your patches does not contain some >> > defconfig, so I still try to figure out what I need to enable to get it >> > working. Maybe it is some missing config entry which should be enabled. >> > >> > But, for me it looks like some devicetree issue, because of_iomem returns >> > NULL, at [0]. Don't know what I am doing wrong. >> >> My best guess is that since you're not using U-Boot, the firmware's >> mangling the DT in some way that breaks us. Notably, in my current >> firmware checkout, set /soc/ranges to just the first entry that we're >> using, which would break the mapping. However, >> rpi/rpi-4.4.y:arch/arm/boot/dts/bcm2709.dtsi uses the same /soc/ranges >> setup that we do, so I'm not sure what's going on. Perhaps >> bcm2709_io_desc[]'s initialization covers for it? > > I boot here with two different bootloaders, both ends in the same panic. > > Finally I figured out if I do a user/kernel split (2G/2G) then the > issue is gone. Huh. Not sure what's going on there. > Later I need to enable "CONFIG_HAVE_ARM_ARCH_TIMER" so the kernel > doesn't hang forever. I'll add a dependency for that -- we definitely want the arch timer. I would have thought that the 2835 timer would still be able to make things work, though. > After finally booting the RPi2 I get several messages of: > > unexpected IRQ trap at vector 00 > > while typing _one_ character over uart. We were doing some debugging of that recently. It seems that every once in a while we get woken up but nothing shows up in the top-level status register. We need to just make the irqchip ignore instead of trying to look up a handler in that case, but I haven't prioritized it because it makes me worry that I'm just papering over a problem in our IRQ masking or something. I haven't seen any problems other than the printk, though. > Can you provide somehow your RPi2 kernelconfig? http://people.freedesktop.org/~anholt/dotconfig-bcm2836-2015-12-22.txt signature.asc Description: PGP signature
[PATCH] mm/memblock: Fix ordering of 'flags' argument in comments
for_each_free_mem_range() and for_each_free_mem_range_reverse() both
accept a 'flags' argument, the comment surrounding the macro placed the
'flags' documentation at the very end, while 'flags' is in fact the 3rd
argument to the macro, so let's preserve natural ordering here.
Fixes: fc6daaf931518 ("mm/memblock: add extra "flags" to memblock to allow
selection of memory based on attribute")
Signed-off-by: Florian Fainelli
---
include/linux/memblock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 24daf8fc4d7c..4303c2981c38 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -209,10 +209,10 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned
long *out_start_pfn,
* for_each_free_mem_range - iterate through free memblock areas
* @i: u64 used as loop variable
* @nid: node selector, %NUMA_NO_NODE for all nodes
+ * @flags: pick from blocks based on memory attributes
* @p_start: ptr to phys_addr_t for start address of the range, can be %NULL
* @p_end: ptr to phys_addr_t for end address of the range, can be %NULL
* @p_nid: ptr to int for nid of the range, can be %NULL
- * @flags: pick from blocks based on memory attributes
*
* Walks over free (memory && !reserved) areas of memblock. Available as
* soon as memblock is initialized.
@@ -225,10 +225,10 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned
long *out_start_pfn,
* for_each_free_mem_range_reverse - rev-iterate through free memblock areas
* @i: u64 used as loop variable
* @nid: node selector, %NUMA_NO_NODE for all nodes
+ * @flags: pick from blocks based on memory attributes
* @p_start: ptr to phys_addr_t for start address of the range, can be %NULL
* @p_end: ptr to phys_addr_t for end address of the range, can be %NULL
* @p_nid: ptr to int for nid of the range, can be %NULL
- * @flags: pick from blocks based on memory attributes
*
* Walks over free (memory && !reserved) areas of memblock in reverse
* order. Available as soon as memblock is initialized.
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: v3020: constify v3020_chip_ops structures
On 11/12/2015 at 18:50:50 +0100, Julia Lawall wrote : > The v3020_chip_ops structures are never modified, so declare them as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- > drivers/rtc/rtc-v3020.c |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: rv8803: fix handling return value of i2c_smbus_read_byte_data
On 10/12/2015 at 08:55:33 +0100, Andrzej Hajda wrote : > The function can return negative values, so its result should > be assigned to signed variable. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107 > > Signed-off-by: Andrzej Hajda > --- > drivers/rtc/rtc-rv8803.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input:touchscreen:Properly check touchscreen information is read in ads7846_probe
On Tue, Dec 22, 2015 at 9:58 AM, Nicholas Krause wrote: > This properly checks if touchscreen information is read before > allocating a sysfs_group of files for this device's device > structure's kobject(s) and if we fail to read the information > successfully then we must continue with the error path for > the error occurred by freeing up resources allocating by > ads7846_probe before returning the error code returned > by this function call to the caller of ads7846_probe. > > Signed-off-by: Nicholas Krause > --- > drivers/input/touchscreen/ads7846.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/touchscreen/ads7846.c > b/drivers/input/touchscreen/ads7846.c > index a61b215..d8150a9 100644 > --- a/drivers/input/touchscreen/ads7846.c > +++ b/drivers/input/touchscreen/ads7846.c > @@ -1412,9 +1412,12 @@ static int ads7846_probe(struct spi_device *spi) > * the touchscreen, in case it's not connected. > */ > if (ts->model == 7845) > - ads7845_read12_ser(>dev, PWRDOWN); > + err = ads7845_read12_ser(>dev, PWRDOWN); > else > - (void) ads7846_read12_ser(>dev, READ_12BIT_SER(vaux)); > + err = ads7846_read12_ser(>dev, READ_12BIT_SER(vaux)); > + > + if (err) > + goto err_remove_hwmon; Positive return value from ads784*_read12_ser() does not indicate error. Also note that when someone takes care annotating an expressions as "(void)" they explicitly indicate that return value should be ignored. For details about why it has been done here you'd have to ask Anatolij Gustschin. > > err = sysfs_create_group(>dev.kobj, _attr_group); > if (err) > -- > 2.5.0 > Nick, it has been proven time and again that your submissions are not useful, please refrain from sending me patches. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] IIO version of INA2xx
On 19/12/15 16:08, Jonathan Cameron wrote: > On 18/12/15 17:23, Marc Titinger wrote: >> v4: >> * squash previous small fixes into one patch and catch up with fixes from >>linux-iio git, 'testing' branch. >> * fix endianness hint by the use of IIO_CPU, following Andrew's comment >> * fix spacing issue. >> * add separate ABI documentation entry >> >> v3 and earlier : see http://www.spinics.net/lists/linux-iio/msg22100.html >> >> Marc Titinger (2): >> iio: ina2xx: add support for TI INA2xx Power Monitors >> iio: ina2xx: add ABI documentation entry sysfs-bus-iio-ina2xx-adc >> >> Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc | 24 + >> drivers/iio/adc/Kconfig| 10 + >> drivers/iio/adc/Makefile | 1 + >> drivers/iio/adc/ina2xx-adc.c | 745 >> + >> 4 files changed, 780 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc >> create mode 100644 drivers/iio/adc/ina2xx-adc.c >> > The togreg branch to which I applied the previous is a non rebasing tree > and a pull request went out to Greg so a new complete version is no use > now. > I've just put together a patch to fixup the wrong endianness issue and applied it to the togreg branch of iio.git as I'm preparing a pull request and want this fixed as this will be the last pull of this cycle. Jonathan > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/vdso: Fix build when CONFIG_KVM_GUEST is not set
From: Borislav Petkov Doing randbuilds fails like this here at link time: arch/x86/built-in.o: In function `arch_setup_additional_pages': /home/boris/kernel/linux/arch/x86/entry/vdso/vma.c:174: undefined reference to `pvclock_pvti_cpu0_va' make: *** [vmlinux] Error 1 This is because pvclock_pvti_cpu0_va() is defined in arch/x86/kernel/kvmclock.c as an accessor to the private hv_clock thing but if CONFIG_KVM_GUEST is not set, we don't have that function to link to. So add CONFIG_KVM_GUEST to the ifdeffery. Signed-off-by: Borislav Petkov --- arch/x86/include/asm/pvclock.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h index 66df22b2e0c9..1af6bee77fb0 100644 --- a/arch/x86/include/asm/pvclock.h +++ b/arch/x86/include/asm/pvclock.h @@ -4,7 +4,7 @@ #include #include -#ifdef CONFIG_PARAVIRT_CLOCK +#if defined(CONFIG_PARAVIRT_CLOCK) && defined(CONFIG_KVM_GUEST) extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void); #else static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void) -- 2.3.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: option.c: Fix Cinterion AHxx enumeration.
[ +CC: linux-usb ]
On Tue, Dec 22, 2015 at 10:51:32AM +, John Ernberg wrote:
> From: John Ernberg
>
> In certain kernel configurations where the cdc_ether and option drivers
> are compiled as modules there can occur a race condition in enumeration.
> This causes the option driver to enumerate the ethernet(wwan) interface
> as usb-serial interfaces.
>
> In dmesg it may look like this:
> [ 18.380585] usb 1-1: new high-speed USB device number 2 using ci_hdrc
> [ 18.592290] usbcore: registered new interface driver usbserial
> [ 18.606636] usbcore: registered new interface driver usbserial_generic
> [ 18.614815] usbserial: USB Serial support registered for generic
> [ 18.652111] usbcore: registered new interface driver option
> [ 18.659745] usbserial: USB Serial support registered for GSM modem (1-port)
> [ 18.667600] option 1-1:1.0: GSM modem (1-port) converter detected
> [ 18.676906] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
> [ 18.686725] cdc_ether 1-1:1.4 wwan0: register 'cdc_ether' at
> usb-ci_hdrc.1-1, Mobile Broadband Network Device
> [ 18.705587] option 1-1:1.1: GSM modem (1-port) converter detected
> [ 18.713468] usbcore: registered new interface driver cdc_ether
> [ 18.719930] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
> [ 18.729770] option 1-1:1.2: GSM modem (1-port) converter detected
> [ 18.737421] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
> [ 18.745232] option 1-1:1.3: GSM modem (1-port) converter detected
> [ 18.752838] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3
> [ 43.422579] option1 ttyUSB3: option_instat_callback: error -71
> [ 43.622575] option1 ttyUSB3: option_instat_callback: error -71
> [ 43.822579] option1 ttyUSB3: option_instat_callback: error -71
> [ 44.022575] option1 ttyUSB3: option_instat_callback: error -71
> [ 44.222569] option1 ttyUSB3: option_instat_callback: error -71
> [ 44.398490] usb 1-1: USB disconnect, device number 2
> [ 44.405414] option1 ttyUSB0: GSM modem (1-port) converter now disconnected
> from ttyUSB0
> [ 44.417200] option 1-1:1.0: device disconnected
> [ 44.424903] option1 ttyUSB1: GSM modem (1-port) converter now disconnected
> from ttyUSB1
> [ 44.434249] option 1-1:1.1: device disconnected
> [ 44.438824] option1 ttyUSB3: option_instat_callback: error -71
> [ 44.448436] option1 ttyUSB2: GSM modem (1-port) converter now disconnected
> from ttyUSB2
> [ 44.457736] option 1-1:1.2: device disconnected
> [ 44.465204] option1 ttyUSB3: GSM modem (1-port) converter now disconnected
> from ttyUSB3
> [ 44.474480] option 1-1:1.3: device disconnected
> [ 44.479754] cdc_ether 1-1:1.4 wwan0: unregister 'cdc_ether' usb-ci_hdrc.1-1,
> Mobile Broadband Network Device
> [ 48.960593] usb 1-1: new high-speed USB device number 3 using ci_hdrc
> [ 49.116118] option 1-1:1.0: GSM modem (1-port) converter detected
> [ 49.123853] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
> [ 49.132029] option 1-1:1.1: GSM modem (1-port) converter detected
> [ 49.138778] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
> [ 49.147432] option 1-1:1.2: GSM modem (1-port) converter detected
> [ 49.154924] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
> [ 49.162940] option 1-1:1.3: GSM modem (1-port) converter detected
> [ 49.169724] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3
> [ 49.178440] option 1-1:1.4: GSM modem (1-port) converter detected
> [ 49.185979] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB4
> [ 49.193985] option 1-1:1.5: GSM modem (1-port) converter detected
> [ 49.201458] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB5
> ---
> drivers/usb/serial/option.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index f228060..4e483f2 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -1679,7 +1679,7 @@ static const struct usb_device_id option_ids[] = {
> { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_EU3_P) },
> { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PH8),
> .driver_info = (kernel_ulong_t)_intf4_blacklist },
> - { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_AHXX) },
> + { USB_DEVICE_INTERFACE_CLASS(CINTERION_VENDOR_ID,
> CINTERION_PRODUCT_AHXX, 0xff) },
> { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLXX),
> .driver_info = (kernel_ulong_t)_intf4_blacklist },
> { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_HC28_MDM) },
Thanks for the patch.
Could you provide the output of lsusb -v for this device?
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/6] mmc: Field Firmware Update
[sigh, in cleartext this time.] 2015-12-22 0:57 GMT-08:00 Ulf Hansson : > + Olof (forgot to add him last time) > > On 22 December 2015 at 09:55, Ulf Hansson wrote: >> + Gwendal, Grant, Olof, Seshagiri, Jon >> >> On 22 December 2015 at 09:15, Holger Schurig wrote: >>> Sorry for the delay. >>> >>> No problem, I was busy with many other projects as well. >>> My advise right now is to try this out via the mmc ioctl in userspace, yes. Although, if you encounter any issues with that approach that it might not be reliable, I am open to look into the in-kernel solution again. >>> >>> I managed to update my Kingston eMMCs with a slighly modified patch to >>> what I submitted. I however didn't bother to submit this, as I saw no >>> chance of getting it applied. >>> >>> Also I once asked in the mailing list if there is some user-space >>> example of how to use the multi-block feature that is supposed to enable >>> this, but I haven't gotten an answer. >>> Regarding mmc-utils as where I recommend you to implement this, I have been thinking of moving this tool into the tools directory in the kernel. >>> >>> Sounds good to me. >>> >>> >>> >>> Remotely related: >>> >>> Do you know that some google people made their own version of mmc-utils >>> for ChromeOS? "Make their own version" makes it sound like we've rewritten it. We haven't. We've applied some patches locally over the last two years based on work we've done for our products. It's not a deep fork. We'd be happy to upstream them if there's interest from other users and maintainers. >> Perhaps by moving the code into the kernel tools dir and finding >> someone who actively wants to maintain it, will enable improved >> upstream activities!? Hmm. If there's a well-defined userspace interface there's little reason to bundle it directly, and I think that's the case here. Chris has been busy with other stuff the last couple of years, is there a lot of mmc-utils code that's out there that hasn't been picked up? -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] clk: samsung: exynos5422: add missing parent GSCL block clocks
On 12/17, Krzysztof Kozlowski wrote: > On 17.12.2015 02:23, Sylwester Nawrocki wrote: > > Krzysztof, > > > > On 09/12/15 14:36, Krzysztof Kozlowski wrote: > >> W dniu 09.12.2015 o 19:14, Sylwester Nawrocki pisze: > Adding Stephen and linux-clk at Cc. > > On 09/12/15 05:49, Krzysztof Kozlowski wrote: > >> On 08.12.2015 22:46, Marek Szyprowski wrote: > >> This patch adds clocks, which are required for preserving parent > >> clock > >> configuration on GSCL power domain on/off. > >> > >> Signed-off-by: Marek Szyprowski > >> --- > >> drivers/clk/samsung/clk-exynos5420.c | 8 > >> include/dt-bindings/clock/exynos5420.h | 2 ++ > >> 2 files changed, 6 insertions(+), 4 deletions(-) > >> > >> I suppose that, with ack from clock folks, this can go through > >> samsung-soc? > > I guess it makes more sense that making a stable branch with just > this patch to be pulled into arm-soc and clk tree. I'm fine with > applying this patch through arm-soc, but I think we also need > Mike's or Stephen ack for this. > > Acked-by: Sylwester Nawrocki > >> > >> I am fine with the branch approach (actually in such cases I make them > >> anyway just in case). > >> > >> As you suggested I'll wait for Mike's or Stepen's acks. > > > > I've put the $subject patch and the other exynos5420 patch which > > was a dependency for dts patches (both touching include/dt-bindings/ > > clock/exynos5420.h) onto a stable branch. Below are details if > > you need to pull. This is superseded by the pull request found in Message-ID: <5671a456.9030...@samsung.com>, correct? Thanks, Mike > > Great! Thanks Sylwester. > BR, > Krzysztof > > > > > > > > The following changes since commit 9f9499ae8e6415cefc4fe0a96ad0e27864353c89: > > > > Linux 4.4-rc5 (2015-12-13 17:42:58 -0800) > > > > are available in the git repository at: > > > > git://linuxtv.org/snawrocki/samsung.git tags/for-4.5-clk-exynos5420 > > > > for you to fetch changes up to bee4f87f01dc30fcf9e05eb55b833f89fd9bb4f4: > > > > clk: samsung: exynos5420: add cpu clock configuration data and > > instantiate cpu clock (2015-12-16 16:35:26 +0100) > > > > > > Samsung exynos5420 SoC clk subsystem support updates: > > instantiation of the cpu clocks and addition of the GSCL > > IP parent clocks to the list of available consumer clocks. > > > > > > Marek Szyprowski (1): > > clk: samsung: exynos542x: add missing parent GSCL block clocks > > > > Thomas Abraham (1): > > clk: samsung: exynos5420: add cpu clock configuration data and > > instantiate cpu clock > > > > drivers/clk/samsung/clk-exynos5420.c | 66 > > +--- > > include/dt-bindings/clock/exynos5420.h |4 ++ > > 2 files changed, 64 insertions(+), 6 deletions(-) > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v2 2/2] ASoC: atmel-classd: DT binding for PDMIC driver
On Sat, Dec 19, 2015 at 5:30 AM, Mark Brown wrote: > On Fri, Dec 18, 2015 at 01:56:21PM -0600, Rob Herring wrote: >> On Thu, Dec 17, 2015 at 05:50:00PM +0800, Songjun Wu wrote: > >> > +- atmel,model >> > + The user-visible name of this sound card. >> > + The default value is "PDMIC". > >> When and why would this be different than the default? > >> "label" can be used here if this is really needed. > > The plastics for the system are often very important for audio > configuration - we need userspace to be able to distinguish between > systems that are identical even on the electrical level. Okay. That is exactly what label is for, so please use it. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
