[PATCH] sit: reload iphdr in ipip6_rcv
Since iptunnel_pull_header() can call pskb_may_pull(),
we must reload any pointer that was related to skb->head.
Fixes: a09a4c8dd1ec ("tunnels: Remove encapsulation offloads on decap")
Signed-off-by: Haishuang Yan
---
net/ipv6/sit.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 61e5902..af832e7 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -657,6 +657,7 @@ static int ipip6_rcv(struct sk_buff *skb)
if (iptunnel_pull_header(skb, 0, htons(ETH_P_IPV6),
!net_eq(tunnel->net, dev_net(tunnel->dev
goto out;
+ iph = ip_hdr(skb);
err = IP_ECN_decapsulate(iph, skb);
if (unlikely(err)) {
--
1.8.3.1
Re: [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
On Sun, Jun 04, 2017 at 01:24:13AM -0400, Matt Brown wrote:
> On 06/03/2017 02:33 AM, Al Viro wrote:
> > On Sat, Jun 03, 2017 at 01:53:51AM -0400, Matt Brown wrote:
> >
> > > +static int tpe_bprm_set_creds(struct linux_binprm *bprm)
> > > +{
> > > + struct file *file = bprm->file;
> > > + struct inode *inode = d_backing_inode(file->f_path.dentry->d_parent);
> > > + struct inode *file_inode = d_backing_inode(file->f_path.dentry);
> >
> > Bloody wonderful. Do tell, what *does* prevent a race with rename(2) here,
> > somehow making sure that your 'inode' won't get freed right under you?
> >
>
> Good catch. How does this look:
>
> spin_lock(&inode->i_lock);
> spin_lock(&file_inode->i_lock);
> if (global_nonroot(inode->i_uid) && !uid_eq(inode->i_uid, cred->uid))
> reason1 = "directory not owned by user";
> else if (inode->i_mode & 0002)
> reason1 = "file in world-writable directory";
> else if ((inode->i_mode & 0020) && global_nonroot_gid(inode->i_gid))
> reason1 = "file in group-writable directory";
> else if (file_inode->i_mode & 0002)
> reason1 = "file is world-writable";
> spin_unlock(&inode->i_lock);
> spin_unlock(&file_inode->i_lock);
>
> and likewise for other places in the code?
Er... You have a pointer to object that might get freed by a thread
running on another CPU. So you attempt to take a spinlock sitting
inside that object. How exactly is that supposed to help anything?
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
On Mon, May 29, 2017 at 8:27 PM, Casey Schaufler wrote: > On 5/29/2017 4:51 PM, Boris Lukashev wrote: >> With all due respect sir, i believe your review falls short of the >> purpose of this effort - to harden the kernel against flaws in >> userspace. Comments along the line of "if does it right >> then your patch is pointless" are not relevant to the context of >> securing kernel functions/interfaces. What userspace should do has >> little bearing on defensive measures actually implemented in the >> kernel - if we took the approach of "someone else is responsible for >> that" in military operations, the world would be a much darker and >> different place today. Those who have the luxury of standoff from the >> critical impacts of security vulnerabilities may not take into account >> the fact that peoples lives literally depend on Linux getting a lot >> more secure, and quickly. > > You are not going to help anyone with a kernel configuration that > breaks agetty, csh, xemacs and tcsh. The opportunities for using > such a configuration are limited. > First off, thank you for the clear and rational responses - newbie status in these upstreaming/kernel matters has a bit of a steep learning curve. I would however, have to disagree with the above in that there is a very large number of purpose built Linux systems in play, home routers being a good example, which effectively retain the same security posture over their lifetime in an increasingly hostile operating environment. Mitigation at every tier of the attack cycle is desirable as a (configurable) default such as to at least reduce the impact of compromise (they may leak memory containing the admin cred for the web ui via some protocol error, but dont get shells, local privs, and raw device access). Then there are all the servers out there which would benefit from this, as they dont use those components but do expose TTYs to dangerous consumers, and even the workstations in a similar boat where they dont depend on faulty consumers but are operated by faulty users. Devil's in the details right? Ideally, if properly designed with input from greybeards, faults can be mostly nullified and edge cases addressed with adjacent maintainers. >> If this work were not valuable, it wouldnt be an enabled kernel option >> on a massive number of kernels with attack surfaces reduced by the >> compound protections offered by the grsec patch set. > > I'll bet you a beverage that 99-44/100% of the people who have > this enabled have no clue that it's even there. And if they did, > most of them would turn it off. > Wouldn't dream of taking that bet - the vast majority of Linux users dont even know they're Linux users :). Disagree with the latter part though, the majority of people rely on the appropriate organs of society (military, police, security-focused devs) to provide for their safety; they not only take for granted but largely abide by the constraints placed by those in the know such as to ensure that safety. A cynical example being that you may not know exactly what the stuff in that hazmat-labled container will do to you (may make you into Wolverine, or melt your bones), but you're not likely to open it and take a sip - you trust the people who sealed it to know enough of the details to have made that decision. Implementing changes like this (properly scoped and implemented, as the refinement process seems to be doing) makes a lot of sense top-down as it forces consumers to do things the right way instead of waiting for them before adopting a useful function. >> I can't speak for >> the grsec people, but having read a small fraction of the commentary >> around the subject of mainline integration, it seems to me that NAKs >> like this are exactly why they had no interest in even trying - this >> review is based on the cultural views of the kernel community, not on >> the security benefits offered by the work in the current state of >> affairs (where userspace is broken). > > A security clamp-down that breaks important stuff is going > to have a tough row to hoe going upstream. Same with a performance > enhancement that breaks things. > Back to the newbie status bit, i've read and heard (in varying degrees of satisfaction and frustration) that upstream makes it hard to adopt significant changes as a culture. Obviously there are practical concerns around compatibility, but there must be some avenue to have a clear and rational discussion with Olympus about inducing a well planned and short period of churn to affect changes which will greatly extend the iconic notion of systems running stable and safe for years at a time... In practical terms, distributions ship tons of patches for kernel bugs faster than you can reload a blunderbuss. While that is good practice, and should continue, it results in constant operating efforts on the parts of the consumer having to "manage their updates" since the bug isn't restricted in access vectors or efficacy by a global defens
Re: get_random_bytes returns bad randomness before seeding is complete
Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld: Hi Jason, > Alternatively, I'm open to other solutions people might come up with. One addition, there is an issue (I would call it a bug) in random.c before 4.8 where the nonblocking_pool is not reseeded during early boot even though entropy may be available. That issue aggravates early boot time entropy issues for user and kernel land. I have not heard about accepting or rejecting it, so I am wondering how patches go into random.c at all. [1] https://patchwork.kernel.org/patch/9620431/ Ciao Stephan
RE: [PATCH v2 08/11] ARC: [plat-eznps] spinlock aware for MTM
> From: Vineet Gupta [mailto:vineet.gup...@synopsys.com] > Sent: Friday, June 2, 2017 21:36 PM ... >> arch/arc/include/asm/spinlock.h |6 ++ >> 1 files changed, 6 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arc/include/asm/spinlock.h >> b/arch/arc/include/asm/spinlock.h index 233d5ff..0a54ce7 100644 >> --- a/arch/arc/include/asm/spinlock.h >> +++ b/arch/arc/include/asm/spinlock.h >> @@ -252,9 +252,15 @@ static inline void arch_spin_lock(arch_spinlock_t >> *lock) >> >> __asm__ __volatile__( >> "1: ex %0, [%1]\n" >> +#ifdef CONFIG_EZNPS_MTM_EXT >> +" .word %3\n" >> +#endif >> " breq %0, %2, 1b\n" >> : "+&r" (val) >> : "r"(&(lock->slock)), "ir"(__ARCH_SPIN_LOCK_LOCKED__) >> +#ifdef CONFIG_EZNPS_MTM_EXT >> +, "i"(CTOP_INST_SCHD_RW) >> +#endif >> : "memory"); >> >> /* >> >This is ugly - I will fix it up here to create an NPS version of >arch_spin_lock ! TNX -Noam
RE: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception
> From: Vineet Gupta [mailto:vineet.gup...@synopsys.com] > Sent: Friday, June 2, 2017 22:04 PM >> diff --git a/arch/arc/plat-eznps/Kconfig b/arch/arc/plat-eznps/Kconfig >> index feaa471..c5f946c 100644 >> --- a/arch/arc/plat-eznps/Kconfig >> +++ b/arch/arc/plat-eznps/Kconfig >> @@ -32,3 +32,14 @@ config EZNPS_MTM_EXT >>any of them seem like CPU from Linux point of view. >>All threads within same core share the execution unit of the >>core and HW scheduler round robin between them. >> + >> +config EZNPS_MEM_ERROR >> + bool "ARC-EZchip Memory error as an exception" >> + depends on ARC_PLAT_EZNPS >> + default n >> + help >> + On the real chip of the NPS, user memory errors are handled >> + as a machine check exception, whereas on simulator platform >> + for NPS, it handled as an interrupt level 2 (like legacy arc >> + real chip architecture).This configuration will cause the kernel >> + to handle memory error as a machine check exception. >Do you really need a Kconfig option here. AFAIKR you guys had some magic in >platform code to determine whether running on sim or hw - can that be not used >? We do not have this anymore, needed to create dedicated one here. ... >> diff --git a/arch/arc/plat-eznps/entry.S b/arch/arc/plat-eznps/entry.S >> index 328261c..03e2892 100644 >> --- a/arch/arc/plat-eznps/entry.S >> +++ b/arch/arc/plat-eznps/entry.S >> @@ -68,3 +68,17 @@ ENTRY(res_service) >> >> j stext >> END(res_service) >> + >> +#if defined(CONFIG_EZNPS_MEM_ERROR) >> +ENTRY(mem_service) >> +; SW workaround to cover up on a difference between >> +; NPS real chip and simulator behaviors. >> +; NPS real chip will activate a machine check exception >> +; in case of memory error, while the simulator will >> +; trigger a level 2 interrupt. Therefor this code section >> +; should be reached only in simulation mode. >> +; DEAD END: display Regs and HALT >> + >> +j EV_MachineCheck >> +END(mem_service) >> +#endif >Just squash the weak symbol patch in here - not worth a separate patch ! Ok , no problem. -Noam
Re: [PATCH 3/4] mfd: da9055-core: make it explicitly non-modular
Hi Paul, [auto build test ERROR on ljones-mfd/for-mfd-next] [also build test ERROR on v4.12-rc3 next-20170602] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paul-Gortmaker/mfd-make-da90xx-drivers-explicitly-non-modular/20170603-211054 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next config: arm-allyesconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm Note: the linux-review/Paul-Gortmaker/mfd-make-da90xx-drivers-explicitly-non-modular/20170603-211054 HEAD c8ab14d7a1d96ff8fb5121c974030c48824d0914 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): drivers/built-in.o: In function `alpine_msix_middle_domain_alloc': supp.c:(.text+0xb8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o supp.c:(.text+0xf0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o supp.c:(.text+0x114): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o supp.c:(.text+0x214): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o supp.c:(.text+0x22c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `alpine_msix_init_domains': supp.c:(.text+0x2d8): relocation truncated to fit: R_ARM_CALL against symbol `of_irq_find_parent' defined in .text section in drivers/built-in.o drivers/built-in.o: In function `alpine_msix_init': supp.c:(.text+0x414): relocation truncated to fit: R_ARM_CALL against symbol `of_address_to_resource' defined in .text section in drivers/built-in.o supp.c:(.text+0x454): relocation truncated to fit: R_ARM_CALL against symbol `of_property_read_variable_u32_array' defined in .text section in drivers/built-in.o supp.c:(.text+0x4c4): relocation truncated to fit: R_ARM_CALL against symbol `of_property_read_variable_u32_array' defined in .text section in drivers/built-in.o drivers/built-in.o: In function `alpine_msix_middle_domain_free': supp.c:(.text+0x5a4): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o supp.c:(.text+0x5bc): additional relocation overflows omitted from the output drivers/built-in.o: In function `da9055_i2c_remove': >> supp.c:(.text+0xa29d98): undefined reference to `da9055_device_exit' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: get_random_bytes returns bad randomness before seeding is complete
Am Sonntag, 4. Juni 2017, 00:54:39 CEST schrieb Jeffrey Walton: Hi Jeffrey, > On Sat, Jun 3, 2017 at 5:45 PM, Sandy Harris wrote: > > ... > > Of course this will fail on systems with no high-res timer. Are there > > still some of those? It might be done in about 1000 times as long on a > > system that lacks the realtime library's nanosecond timer but has the > > Posix standard microsecond timer, implying a delay time in the > > milliseconds. Would that be acceptable in those cases? > > A significant portion of the use cases should include mobile devices. > Device sales outnumbered desktop and server sales several years ago. > > Many devices are sensor rich. Even the low-end ones come with > accelorometers for gaming. A typical one has 3 or 4 sensors, and > higher-end ones have 7 or 8 sensors. An Evo 4G has 7 of them. > I think those devices are covered with the kernels 4.8+. That kernel uses solely interrupts as noise source for the first stage we talk about here. Not having done any particular measurements with the latest kernels on mobile devices, but based on my experience with my LRNG assessment, I could fathom that mobile devices have a fully seeded ChaCha20 DRNG before user space starts. Just to give an illustration: I have a Lenovo T540 which receives more than 256 interrupts before late_initcall. On all system with a high-res timer, each interrupt will give more than one bit of entropy. Conversely, on my MacBook Pro 2015, at late_initcall the kernel received less than 100 interrupts. In a KVM guest with very little devices, I also have some 100 interrupts before late_initcall. These measurements are taken with the same kernel and same kernel configs. Ciao Stephan
Re: get_random_bytes returns bad randomness before seeding is complete
On Sun, Jun 4, 2017 at 1:48 AM, Stephan Müller wrote: > Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld: > >> Alternatively, I'm open to other solutions people might come up with. > > How about stirring in some data from the Jitter RNG that we have in the kernel > already and that is used for the DRBG in case get_random_bytes has > insufficient entropy? Yes, two kernel developers said that this RNG is > useless, where in fact a lot of hardware and even crypto folks say that this > approach has merits. Almost anything has to be better than (1) silent failures, and (2) draining the little entropy available when the generators are starting and trying to become operational. The [negative] use case for (2) is systemd. See, for example, https://github.com/systemd/systemd/issues/4167. Jeff
Re: [PATCH 3/4] mfd: da9055-core: make it explicitly non-modular
Hi Paul, [auto build test ERROR on ljones-mfd/for-mfd-next] [also build test ERROR on v4.12-rc3 next-20170602] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paul-Gortmaker/mfd-make-da90xx-drivers-explicitly-non-modular/20170603-211054 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next config: s390-allmodconfig (attached as .config) compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=s390 Note: the linux-review/Paul-Gortmaker/mfd-make-da90xx-drivers-explicitly-non-modular/20170603-211054 HEAD c8ab14d7a1d96ff8fb5121c974030c48824d0914 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): drivers/built-in.o: In function `da9055_i2c_remove': >> drivers/mfd/.tmp_gl_da9055-i2c.o:(.text+0x17860e): undefined reference to >> `da9055_device_exit' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: get_random_bytes returns bad randomness before seeding is complete
Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld: Hi Jason, > > Alternatively, I'm open to other solutions people might come up with. How about stirring in some data from the Jitter RNG that we have in the kernel already and that is used for the DRBG in case get_random_bytes has insufficient entropy? Yes, two kernel developers said that this RNG is useless, where in fact a lot of hardware and even crypto folks say that this approach has merits. In any case, it cannot destroy the (not present) entropy at boot time anyway. Thus, take some 32, 48 or 64 bytes from it right at the start of the kernel, and we should be better (from the view point of quite some folks) or not worse off (view point of two developers here). As this RNG does not depend on any in-kernel facility, it is always available at any time. PS: I could revive a patch adding this to random.c that I sent long ago if desired. Ciao Stephan
Re: [kernel-hardening] Re: [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
On Sun, Jun 04, 2017 at 01:24:13AM -0400, Matt Brown wrote:
> On 06/03/2017 02:33 AM, Al Viro wrote:
> > On Sat, Jun 03, 2017 at 01:53:51AM -0400, Matt Brown wrote:
> >
> > > +static int tpe_bprm_set_creds(struct linux_binprm *bprm)
> > > +{
> > > + struct file *file = bprm->file;
> > > + struct inode *inode = d_backing_inode(file->f_path.dentry->d_parent);
> > > + struct inode *file_inode = d_backing_inode(file->f_path.dentry);
> >
> > Bloody wonderful. Do tell, what *does* prevent a race with rename(2) here,
> > somehow making sure that your 'inode' won't get freed right under you?
> >
>
> Good catch. How does this look:
>
> spin_lock(&inode->i_lock);
> spin_lock(&file_inode->i_lock);
> if (global_nonroot(inode->i_uid) && !uid_eq(inode->i_uid, cred->uid))
> reason1 = "directory not owned by user";
> else if (inode->i_mode & 0002)
> reason1 = "file in world-writable directory";
> else if ((inode->i_mode & 0020) && global_nonroot_gid(inode->i_gid))
> reason1 = "file in group-writable directory";
> else if (file_inode->i_mode & 0002)
> reason1 = "file is world-writable";
> spin_unlock(&inode->i_lock);
> spin_unlock(&file_inode->i_lock);
>
> and likewise for other places in the code?
No, it needs to take a reference on the parent dentry before using it, using
dget_parent(), I think, and then dropping it later with dput(). Taking i_lock
isn't needed.
Eric
Re: [RFC v2 2/4] tracing: Add support for recording tgid of tasks
Some minor things that I will rework in next rev after spending some
more time on it:
On Sat, Jun 3, 2017 at 9:03 PM, Joel Fernandes wrote:
[..]
> @@ -463,7 +469,7 @@ int trace_set_clr_event(const char *system, const char
> *event, int set);
> #define event_trace_printk(ip, fmt, args...) \
> do { \
> __trace_printk_check_format(fmt, ##args); \
> - tracing_record_cmdline(current);\
> + tracing_record_taskinfo_single(current, true, false); \
> if (__builtin_constant_p(fmt)) {\
> static const char *trace_printk_fmt \
> __attribute__((section("__trace_printk_fmt"))) = \
> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> index 193c5f5e3f79..d7394cdf899e 100644
> --- a/kernel/trace/blktrace.c
> +++ b/kernel/trace/blktrace.c
> @@ -236,7 +236,7 @@ static void __blk_add_trace(struct blk_trace *bt,
> sector_t sector, int bytes,
> cpu = raw_smp_processor_id();
>
> if (blk_tracer) {
> - tracing_record_cmdline(current);
> + tracing_record_taskinfo_single(current, true, false);
I think I will try to preserve the existing API so that existing users
aren't bothered much.
>
> buffer = blk_tr->trace_buffer.buffer;
> pc = preempt_count();
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 63deff9cdf2c..7be21ae4f0a8 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -87,7 +87,7 @@ dummy_set_flag(struct trace_array *tr, u32 old_flags, u32
> bit, int set)
> * tracing is active, only save the comm when a trace event
> * occurred.
> */
> -static DEFINE_PER_CPU(bool, trace_cmdline_save);
> +static DEFINE_PER_CPU(bool, trace_taskinfo_save);
>
> /*
> * Kill all tracing for good (never come back).
> @@ -790,7 +790,7 @@ EXPORT_SYMBOL_GPL(tracing_on);
> static __always_inline void
> __buffer_unlock_commit(struct ring_buffer *buffer, struct ring_buffer_event
> *event)
> {
> - __this_cpu_write(trace_cmdline_save, true);
> + __this_cpu_write(trace_taskinfo_save, true);
>
> /* If this is the temp buffer, we need to commit fully */
> if (this_cpu_read(trace_buffered_event) == event) {
> @@ -1709,6 +1709,15 @@ void tracing_reset_all_online_cpus(void)
> }
> }
>
> +static unsigned int *tgid_map;
> +
> +void tracing_alloc_tgid_map(void)
> +{
> + tgid_map = kzalloc((PID_MAX_DEFAULT + 1) * sizeof(*tgid_map),
> + GFP_KERNEL);
> + WARN_ONCE(!tgid_map, "Allocation of tgid_map failed\n");
I should check if tgid_map is already allocated or there's a chance of
re-allocating.
Looking forward to any other comments...
thanks,
-Joel
Re: [PATCH v2 02/20] staging: ccree: replace bit shift with BIT macro
On Sat, Jun 3, 2017 at 11:46 AM, Greg Kroah-Hartman wrote: > On Thu, Jun 01, 2017 at 02:02:52PM +0300, Gilad Ben-Yossef wrote: >> CC_CTX_SIZE was being defined using a hand rolled bit shift operation. >> Replace with use of BIT macro. >> >> Signed-off-by: Gilad Ben-Yossef >> --- >> drivers/staging/ccree/cc_crypto_ctx.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > This patch didn't apply at all, are you sure you are working against the > correct tree? I've tried to apply some of this series, but most do not > work at all... > Yes, I did. The patch series was created against your staging/staging-next at commit ca9280d1f82a7a0165a683dc09f182329ebec352 What I believe might have happened is that you took in Gennadii Altukhov's and Derek Robson's patch set and mine indeed no longer applies on top of theirs. > Please rebase against my staging-next branch and resend the ones that do > work. Sure, I'll rebase on top of current staging/staging-next and resend the remaining patches Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
On 06/03/2017 02:33 AM, Al Viro wrote:
On Sat, Jun 03, 2017 at 01:53:51AM -0400, Matt Brown wrote:
+static int tpe_bprm_set_creds(struct linux_binprm *bprm)
+{
+ struct file *file = bprm->file;
+ struct inode *inode = d_backing_inode(file->f_path.dentry->d_parent);
+ struct inode *file_inode = d_backing_inode(file->f_path.dentry);
Bloody wonderful. Do tell, what *does* prevent a race with rename(2) here,
somehow making sure that your 'inode' won't get freed right under you?
Good catch. How does this look:
spin_lock(&inode->i_lock);
spin_lock(&file_inode->i_lock);
if (global_nonroot(inode->i_uid) && !uid_eq(inode->i_uid, cred->uid))
reason1 = "directory not owned by user";
else if (inode->i_mode & 0002)
reason1 = "file in world-writable directory";
else if ((inode->i_mode & 0020) && global_nonroot_gid(inode->i_gid))
reason1 = "file in group-writable directory";
else if (file_inode->i_mode & 0002)
reason1 = "file is world-writable";
spin_unlock(&inode->i_lock);
spin_unlock(&file_inode->i_lock);
and likewise for other places in the code?
Investment Interest & Offer
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver
On 06/03/2017 02:57 PM, Sakari Ailus wrote: On Sat, Jun 03, 2017 at 09:51:39PM +0200, Pavel Machek wrote: Hi! + /* Auto/manual exposure */ + ctrls->auto_exp = v4l2_ctrl_new_std_menu(hdl, ops, +V4L2_CID_EXPOSURE_AUTO, +V4L2_EXPOSURE_MANUAL, 0, +V4L2_EXPOSURE_AUTO); + ctrls->exposure = v4l2_ctrl_new_std(hdl, ops, + V4L2_CID_EXPOSURE_ABSOLUTE, + 0, 65535, 1, 0); Is exposure_absolute supposed to be in microseconds...? Yes. According to the docs V4L2_CID_EXPOSURE_ABSOLUTE is in 100 usec units. OTOH V4L2_CID_EXPOSURE has no defined unit, so it's a better fit IMO. Way more drivers appear to be using EXPOSURE than EXPOSURE_ABSOLUTE, too. Done, switched to V4L2_CID_EXPOSURE. It's true, this control is not taking 100 usec units, so unit-less is better. Thanks. If you know the units, it would be of course better to use right units... Steve: what's the unit in this case? Is it lines or something else? Yes, the register interface for exposure takes lines*16. Maybe converting from seconds to lines is as simple as framerate * height * seconds. But I'm not sure about that. Steve Pavel: we do need to make sure the user space will be able to know the unit, too. It's rather a case with a number of controls: the unit is known but there's no API to convey it to the user. The exposure is a bit special, too: granularity matters a lot on small values. On most other controls it does not.
Re: [PATCH 2/5] x86/cpuid: Add generic table for cpuid dependencies
Hi Andi, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.12-rc3 next-20170602] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andi-Kleen/x86-xsave-Move-xsave-initialization-to-after-parsing-early-parameters/20170601-085802 config: i386-randconfig-h0-06040930 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "clear_cpu_cap" [drivers/lguest/lg.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] tcmu: Add fifo type waiter list support to avoid starvation
On 05/04/2017 09:51 PM, lixi...@cmss.chinamobile.com wrote:
> From: Xiubo Li
>
> The fifo type waiter list will hold the udevs who are waiting for the
> blocks from the data global pool. The unmap thread will try to feed the
> first udevs in waiter list, if the global free blocks available are
> not enough, it will stop traversing the list and abort waking up the
> others.
>
> Signed-off-by: Xiubo Li
> ---
> drivers/target/target_core_user.c | 82
> +++
> 1 file changed, 66 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/target/target_core_user.c
> b/drivers/target/target_core_user.c
> index 9045837..10c99e7 100644
> --- a/drivers/target/target_core_user.c
> +++ b/drivers/target/target_core_user.c
> @@ -97,6 +97,7 @@ struct tcmu_hba {
>
> struct tcmu_dev {
> struct list_head node;
> + struct list_head waiter;
>
> struct se_device se_dev;
>
> @@ -123,7 +124,7 @@ struct tcmu_dev {
> wait_queue_head_t wait_cmdr;
> struct mutex cmdr_lock;
>
> - bool waiting_global;
> + uint32_t waiting_blocks;
> uint32_t dbi_max;
> uint32_t dbi_thresh;
> DECLARE_BITMAP(data_bitmap, DATA_BLOCK_BITS);
> @@ -165,6 +166,10 @@ struct tcmu_cmd {
> static DEFINE_MUTEX(root_udev_mutex);
> static LIST_HEAD(root_udev);
>
> +/* The data blocks global pool waiter list */
> +static DEFINE_MUTEX(root_udev_waiter_mutex);
Sorry for the delay.
Could you just add a comment about the lock ordering. It will be helpful
to new engineers/reviewers to check for errors.
> +static LIST_HEAD(root_udev_waiter);
> +
> static atomic_t global_db_count = ATOMIC_INIT(0);
>
> static struct kmem_cache *tcmu_cmd_cache;
> @@ -195,6 +200,11 @@ enum tcmu_multicast_groups {
> #define tcmu_cmd_set_dbi(cmd, index) ((cmd)->dbi[(cmd)->dbi_cur++] = (index))
> #define tcmu_cmd_get_dbi(cmd) ((cmd)->dbi[(cmd)->dbi_cur++])
>
> +static inline bool is_in_waiter_list(struct tcmu_dev *udev)
> +{
> + return !!udev->waiting_blocks;
> +}
> +
> static void tcmu_cmd_free_data(struct tcmu_cmd *tcmu_cmd, uint32_t len)
> {
> struct tcmu_dev *udev = tcmu_cmd->tcmu_dev;
> @@ -250,8 +260,6 @@ static bool tcmu_get_empty_blocks(struct tcmu_dev *udev,
> {
> int i;
>
> - udev->waiting_global = false;
> -
> for (i = tcmu_cmd->dbi_cur; i < tcmu_cmd->dbi_cnt; i++) {
> if (!tcmu_get_empty_block(udev, tcmu_cmd))
> goto err;
> @@ -259,9 +267,7 @@ static bool tcmu_get_empty_blocks(struct tcmu_dev *udev,
> return true;
>
> err:
> - udev->waiting_global = true;
> - /* Try to wake up the unmap thread */
> - wake_up(&unmap_wait);
> + udev->waiting_blocks += tcmu_cmd->dbi_cnt - i;
> return false;
> }
>
> @@ -671,6 +677,7 @@ static inline size_t tcmu_cmd_get_cmd_size(struct
> tcmu_cmd *tcmu_cmd,
>
> while (!is_ring_space_avail(udev, tcmu_cmd, command_size, data_length))
> {
> int ret;
> + bool is_waiting_blocks = !!udev->waiting_blocks;
You can use your helper is_in_waiter_list().
> DEFINE_WAIT(__wait);
>
> prepare_to_wait(&udev->wait_cmdr, &__wait, TASK_INTERRUPTIBLE);
> @@ -688,6 +695,18 @@ static inline size_t tcmu_cmd_get_cmd_size(struct
> tcmu_cmd *tcmu_cmd,
> return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
> }
>
> + /*
> + * Try to insert the current udev to waiter list and
> + * then wake up the unmap thread
> + */
> + if (is_waiting_blocks) {
> + mutex_lock(&root_udev_waiter_mutex);
> + list_add_tail(&udev->waiter, &root_udev_waiter);
> + mutex_unlock(&root_udev_waiter_mutex);
> +
> + wake_up(&unmap_wait);
> + }
Is this supposed to go before the schedule_timeout call?
If we are here and schedule_timeout returned non zero then our wait_cmdr
has been woken up from the unmap thread because it freed some space, so
we do not want to again add ourself and call unmap again.
> +
> mutex_lock(&udev->cmdr_lock);
>
> /* We dropped cmdr_lock, cmd_head is stale */
> @@ -902,8 +921,6 @@ static unsigned int tcmu_handle_completions(struct
> tcmu_dev *udev)
> if (mb->cmd_tail == mb->cmd_head)
> del_timer(&udev->timeout); /* no more pending cmds */
>
> - wake_up(&udev->wait_cmdr);
> -
> return handled;
> }
>
> @@ -996,7 +1013,17 @@ static int tcmu_irqcontrol(struct uio_info *info, s32
> irq_on)
> struct tcmu_dev *tcmu_dev = container_of(info, struct tcmu_dev,
> uio_info);
>
> mutex_lock(&tcmu_dev->cmdr_lock);
> - tcmu_handle_completions(tcmu_dev);
> + /*
> + * If the current udev is also in waiter list, this will
> + * make sure that the other waiters in list be feeded ahead
> + * of it.
> + */
> + if (is_in_waiter_
[RFC v2 4/4] tracing/ftrace: Add support to record and display tgid
Make function tracer able to record tgid if/when record-tgid is enabled.
Cc: kernel-t...@android.com
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Joel Fernandes
---
kernel/trace/trace_functions.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index 05da1e7513f6..290a7a80abf2 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -27,6 +27,7 @@ static void
function_stack_trace_call(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *op, struct pt_regs *pt_regs);
static struct tracer_flags func_flags;
+static bool tgid_recorded;
/* Our option */
enum {
@@ -103,7 +104,8 @@ static int function_trace_init(struct trace_array *tr)
tr->trace_buffer.cpu = get_cpu();
put_cpu();
- tracing_start_taskinfo_record(true, false);
+ tgid_recorded = tr->trace_flags & TRACE_ITER_RECORD_TGID;
+ tracing_start_taskinfo_record(true, tgid_recorded);
tracing_start_function_trace(tr);
return 0;
@@ -112,7 +114,8 @@ static int function_trace_init(struct trace_array *tr)
static void function_trace_reset(struct trace_array *tr)
{
tracing_stop_function_trace(tr);
- tracing_stop_taskinfo_record(true, false);
+ tracing_stop_taskinfo_record(true, tgid_recorded);
+ tgid_recorded = false;
ftrace_reset_array_ops(tr);
}
@@ -253,6 +256,21 @@ func_set_flag(struct trace_array *tr, u32 old_flags, u32
bit, int set)
return 0;
}
+static int
+func_tracer_flag_changed(struct trace_array *tr, unsigned int mask,
+int enabled)
+{
+ if (mask == TRACE_ITER_RECORD_TGID) {
+ tgid_recorded = !!enabled;
+ if (enabled)
+ tracing_start_taskinfo_record(false, true);
+ else
+ tracing_stop_taskinfo_record(false, true);
+ }
+
+ return 0;
+}
+
static struct tracer function_trace __tracer_data =
{
.name = "function",
@@ -261,6 +279,7 @@ static struct tracer function_trace __tracer_data =
.start = function_trace_start,
.flags = &func_flags,
.set_flag = func_set_flag,
+ .flag_changed = func_tracer_flag_changed,
.allow_instances = true,
#ifdef CONFIG_FTRACE_SELFTEST
.selftest = trace_selftest_startup_function,
--
2.13.0.506.g27d5fe0cd-goog
Re: [PATCH] acpi/iort, numa: Add numa node mapping for smmuv3 devices
On Fri, Jun 2, 2017 at 9:20 AM, Hanjun Guo wrote:
> [+Cc Lv Zheng]
>
> On 2017/6/2 0:21, Lorenzo Pieralisi wrote:
>> On Thu, Jun 01, 2017 at 07:35:37PM +0530, Ganapatrao Kulkarni wrote:
>>> ARM IORT specification has provision to define Proximity domain
>>> in SMMUv3 IORT table. Adding required code to parse Proximity domain of
>>> SMMUv3 IORT table. Parsed Proximity domain is used to set numa_node
>>> of SMMUv3 platform devices.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni
>>> ---
>>> drivers/iommu/arm-smmu-v3.c | 6 ++
>>> include/acpi/actbl2.h | 4
>>> 2 files changed, 10 insertions(+)
>>>
>>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>>> index 69d8506..98c2319 100644
>>> --- a/drivers/iommu/arm-smmu-v3.c
>>> +++ b/drivers/iommu/arm-smmu-v3.c
>>> @@ -2667,6 +2667,12 @@ static int arm_smmu_device_acpi_probe(struct
>>> platform_device *pdev,
>>> if (iort_smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE)
>>> smmu->features |= ARM_SMMU_FEAT_COHERENCY;
>>>
>>> +/* set numa proximity domain for smmv3 device */
>>> +if (iort_smmu->flags & ACPI_IORT_SMMU_V3_PXM) {
>>> +set_dev_node(dev, acpi_map_pxm_to_node(iort_smmu->pxm));
>>> +dev_info(dev, "on NUMA node %d\n", dev_to_node(dev));
>> It should be done in acpi/arm64/iort.c at device creation time.
>
> Agreed.
thanks Lorenzo, i will update in next patch version.
>
>>
>>> +}
>>> +
>>> return 0;
>>> }
>>> #else
>>> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
>>> index 4b306a6..c16ced8 100644
>>> --- a/include/acpi/actbl2.h
>>> +++ b/include/acpi/actbl2.h
>>> @@ -805,6 +805,9 @@ struct acpi_iort_smmu_v3 {
>>> u32 pri_gsiv;
>>> u32 gerr_gsiv;
>>> u32 sync_gsiv;
>>> +u8 pxm;
>>> +u8 reserved1;
>>> +u16 reserved2;
>
> I think changes to actbl2.h need to be split as a new patch
> which go via ACPICA updates, Lv, could you share
> your comments here?
thanks Hanjun, looks like the changes should go to acpica repo and it should get
pulled in kernel.
Lv, can you please suggest on what should be done?
>
> Thanks
> Hanjun
>
thanks
Ganapat
[RFC v2 3/4] tracing: Add support for display of tgid in trace output
Earlier patches introduced ability to record the tgid using the 'record-tgid'
option. Here we read the tgid and output it if the option is enabled.
Cc: kernel-t...@android.com
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Joel Fernandes
---
kernel/trace/trace.c| 47 -
kernel/trace/trace_output.c | 9 +
2 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7be21ae4f0a8..5883498754a1 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3294,23 +3294,42 @@ static void print_event_info(struct trace_buffer *buf,
struct seq_file *m)
seq_puts(m, "#\n");
}
-static void print_func_help_header(struct trace_buffer *buf, struct seq_file
*m)
+static void print_func_help_header(struct trace_buffer *buf, struct seq_file
*m,
+ unsigned int flags)
{
print_event_info(buf, m);
- seq_puts(m, "# TASK-PID CPU# TIMESTAMP FUNCTION\n"
- "# | | | | |\n");
+ if (!(flags & TRACE_ITER_RECORD_TGID)) {
+ seq_puts(m, "# TASK-PID CPU# TIMESTAMP
FUNCTION\n"
+ "# | | | |
|\n");
+ return;
+ }
+
+ seq_puts(m, "# TASK-PID CPU# TGID TIMESTAMP
FUNCTION\n"
+ "# | | | | |
|\n");
}
-static void print_func_help_header_irq(struct trace_buffer *buf, struct
seq_file *m)
+static void print_func_help_header_irq(struct trace_buffer *buf, struct
seq_file *m,
+ unsigned int flags)
{
print_event_info(buf, m);
- seq_puts(m, "# _-=> irqs-off\n"
- "# / _=> need-resched\n"
- "#| / _---=> hardirq/softirq\n"
- "#|| / _--=> preempt-depth\n"
- "#||| / delay\n"
- "# TASK-PID CPU# TIMESTAMP FUNCTION\n"
- "# | | | | |\n");
+ if (!(flags & TRACE_ITER_RECORD_TGID)) {
+ seq_puts(m, "# _-=> irqs-off\n"
+ "# / _=>
need-resched\n"
+ "#| / _---=>
hardirq/softirq\n"
+ "#|| / _--=>
preempt-depth\n"
+ "#||| / delay\n"
+ "# TASK-PID CPU# TIMESTAMP
FUNCTION\n"
+ "# | | | |
|\n");
+ return;
+ }
+
+ seq_puts(m, "# _-=> irqs-off\n"
+ "# / _=>
need-resched\n"
+ "#| / _---=>
hardirq/softirq\n"
+ "#|| / _--=>
preempt-depth\n"
+ "#||| / delay\n"
+ "# TASK-PID CPU# TGID TIMESTAMP
FUNCTION\n"
+ "# | | | | |
|\n");
}
void
@@ -3626,9 +3645,11 @@ void trace_default_header(struct seq_file *m)
} else {
if (!(trace_flags & TRACE_ITER_VERBOSE)) {
if (trace_flags & TRACE_ITER_IRQ_INFO)
- print_func_help_header_irq(iter->trace_buffer,
m);
+ print_func_help_header_irq(iter->trace_buffer,
+ m, trace_flags);
else
- print_func_help_header(iter->trace_buffer, m);
+ print_func_help_header(iter->trace_buffer, m,
+ trace_flags);
}
}
}
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 08f9bab8089e..55c743295874 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -587,6 +587,15 @@ int trace_print_context(struct trace_iterator *iter)
trace_seq_printf(s, "%16s-%-5d [%03d] ",
comm, entry->pid, iter->cpu);
+ if (tr->trace_flags & TRACE_ITER_RECORD_TGID) {
+ unsigned int tgid = trace_find_tgid(entry->pid);
+
+ if (!tgid)
+ trace_seq_printf(s, "(-) ");
+ else
+ trace
[RFC v2 2/4] tracing: Add support for recording tgid of tasks
Inorder to support recording of tgid, the following changes are made:
- Introduce a new API for optionally recording the tgid along with the task's
comm which replaces the existing '*cmdline*' APIs.
- reuse the existing sched_switch and sched_wakeup probes
- replace all uses of the old API
- add a new option 'record-tgid' to enable recording of tgid
This will have no memory or runtime overhead if record-tgid option isn't
enabled.
Cc: kernel-t...@android.com
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Joel Fernandes
---
include/linux/trace_events.h | 10 -
kernel/trace/blktrace.c | 2 +-
kernel/trace/trace.c | 79 --
kernel/trace/trace.h | 9 +++-
kernel/trace/trace_events.c | 83 ++--
kernel/trace/trace_functions.c | 5 ++-
kernel/trace/trace_functions_graph.c | 4 +-
kernel/trace/trace_sched_switch.c| 67 +
kernel/trace/trace_selftest.c| 2 +-
9 files changed, 208 insertions(+), 53 deletions(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index a556805eff8a..bc54f1469971 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -151,7 +151,11 @@ trace_event_buffer_lock_reserve(struct ring_buffer
**current_buffer,
int type, unsigned long len,
unsigned long flags, int pc);
-void tracing_record_cmdline(struct task_struct *tsk);
+void tracing_record_taskinfo(struct task_struct **tasks, int len, bool cmd,
+bool tgid);
+
+void tracing_record_taskinfo_single(struct task_struct *task, bool cmd,
+ bool tgid);
int trace_output_call(struct trace_iterator *iter, char *name, char *fmt, ...);
@@ -290,6 +294,7 @@ struct trace_subsystem_dir;
enum {
EVENT_FILE_FL_ENABLED_BIT,
EVENT_FILE_FL_RECORDED_CMD_BIT,
+ EVENT_FILE_FL_RECORDED_TGID_BIT,
EVENT_FILE_FL_FILTERED_BIT,
EVENT_FILE_FL_NO_SET_FILTER_BIT,
EVENT_FILE_FL_SOFT_MODE_BIT,
@@ -315,6 +320,7 @@ enum {
enum {
EVENT_FILE_FL_ENABLED = (1 << EVENT_FILE_FL_ENABLED_BIT),
EVENT_FILE_FL_RECORDED_CMD = (1 << EVENT_FILE_FL_RECORDED_CMD_BIT),
+ EVENT_FILE_FL_RECORDED_TGID = (1 <<
EVENT_FILE_FL_RECORDED_TGID_BIT),
EVENT_FILE_FL_FILTERED = (1 << EVENT_FILE_FL_FILTERED_BIT),
EVENT_FILE_FL_NO_SET_FILTER = (1 <<
EVENT_FILE_FL_NO_SET_FILTER_BIT),
EVENT_FILE_FL_SOFT_MODE = (1 << EVENT_FILE_FL_SOFT_MODE_BIT),
@@ -463,7 +469,7 @@ int trace_set_clr_event(const char *system, const char
*event, int set);
#define event_trace_printk(ip, fmt, args...) \
do { \
__trace_printk_check_format(fmt, ##args); \
- tracing_record_cmdline(current);\
+ tracing_record_taskinfo_single(current, true, false); \
if (__builtin_constant_p(fmt)) {\
static const char *trace_printk_fmt \
__attribute__((section("__trace_printk_fmt"))) = \
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 193c5f5e3f79..d7394cdf899e 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -236,7 +236,7 @@ static void __blk_add_trace(struct blk_trace *bt, sector_t
sector, int bytes,
cpu = raw_smp_processor_id();
if (blk_tracer) {
- tracing_record_cmdline(current);
+ tracing_record_taskinfo_single(current, true, false);
buffer = blk_tr->trace_buffer.buffer;
pc = preempt_count();
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 63deff9cdf2c..7be21ae4f0a8 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -87,7 +87,7 @@ dummy_set_flag(struct trace_array *tr, u32 old_flags, u32
bit, int set)
* tracing is active, only save the comm when a trace event
* occurred.
*/
-static DEFINE_PER_CPU(bool, trace_cmdline_save);
+static DEFINE_PER_CPU(bool, trace_taskinfo_save);
/*
* Kill all tracing for good (never come back).
@@ -790,7 +790,7 @@ EXPORT_SYMBOL_GPL(tracing_on);
static __always_inline void
__buffer_unlock_commit(struct ring_buffer *buffer, struct ring_buffer_event
*event)
{
- __this_cpu_write(trace_cmdline_save, true);
+ __this_cpu_write(trace_taskinfo_save, true);
/* If this is the temp buffer, we need to commit fully */
if (this_cpu_read(trace_buffered_event) == event) {
@@ -1709,6 +1709,15 @@ void tracing_reset_all_online_cpus(void)
}
}
+static unsigned int *tgid_map;
+
+void tracing_alloc_tgid_map(void)
+{
+ tgid_map = kzalloc((PID_MAX_DEFAULT + 1) * siz
[RFC v2 1/4] tracing: Remove unused declaration of trace_stop_cmdline_recording
trace_stop_cmdline_recording declaration isn't in use, remove it.
Cc: kernel-t...@android.com
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Joel Fernandes
---
kernel/trace/trace.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 1122f151466f..63deff9cdf2c 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1910,8 +1910,6 @@ static void tracing_stop_tr(struct trace_array *tr)
raw_spin_unlock_irqrestore(&tr->start_lock, flags);
}
-void trace_stop_cmdline_recording(void);
-
static int trace_save_cmdline(struct task_struct *tsk)
{
unsigned pid, idx;
--
2.13.0.506.g27d5fe0cd-goog
[RFC v2 0/4] tracing: Add support to record and display tgid of tasks
Hi Steven, Ingo, Here is a rework of the last RFC [1] I posted. Its a a complete rewrite from scratch to be more upstream friendly. Android systrace viewer heavily depends on the tgid to group tasks. tgid is also useful for analyzing traces and generating stats for groups of tasks. Basically in this approach I try to make sure there is no overhead in terms of runtime or space usage for existing users who don't need tgid. Only if the trace option is enabled will the tgid table which does the mapping be allocated and used. I tested these and they are showing good results so far, looking forward to getting your feedback and thoughts on them. Thank you. [1] https://patchwork.kernel.org/patch/9728283/ Joel Fernandes (4): tracing: Remove unused declaration of trace_stop_cmdline_recording tracing: Add support for recording tgid of tasks tracing: Add support for display of tgid in trace output tracing/ftrace: Add support to record and display tgid include/linux/trace_events.h | 10 ++- kernel/trace/blktrace.c | 2 +- kernel/trace/trace.c | 141 +++ kernel/trace/trace.h | 9 ++- kernel/trace/trace_events.c | 84 ++--- kernel/trace/trace_functions.c | 24 +- kernel/trace/trace_functions_graph.c | 4 +- kernel/trace/trace_output.c | 9 +++ kernel/trace/trace_sched_switch.c| 67 - kernel/trace/trace_selftest.c| 2 +- 10 files changed, 283 insertions(+), 69 deletions(-) Cc: Steven Rostedt Cc: Ingo Molnar Cc: kernel-t...@android.com Signed-off-by: Joel Fernandes -- 2.13.0.506.g27d5fe0cd-goog
Re: [PATCH] ARM: imx_v6_v7_defconfig: Explicitly restore CONFIG_DEBUG_FS
On Fri, May 26, 2017 at 02:26:06PM +0300, Leonard Crestez wrote:
> This option was removed by "make savedefconfig" in
> commit c5054a98bce4 ("ARM: imx_v6_v7_defconfig: Select SMSC_PHY")
>
> This happened because CONFIG_DEBUG_FS was implicitly selected by
> CONFIG_TREE_RCU_TRACE which defaulted to true because CONFIG_RCU_TRACE
> was enabled by default by commit 961518259b3b ("rcu: Enable RCU
> tracepoints by default to aid in debugging")
>
> Recently however CONFIG_RCU_TRACE was completely removed by
> commit 6e74c237c410 ("rcu: Remove debugfs tracing")
>
> The result is that imx_v6_v7_defconfig no longer includes DEBUG_FS on
> linux-next since next-20170517. This is bad, DEBUG_FS is extremely
> useful for kernel introspection and testing.
>
> Signed-off-by: Leonard Crestez
Applied, thanks.
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
On Sun, Jun 4, 2017 at 8:22 AM, Matt Brown wrote: > On 06/03/2017 06:00 PM, Alan Cox wrote: >>> >>> TIOCSLCKTRMIOS >> >> >> That one I'm more dubious about >> >>> TIOCSLTC >>> TIOCSSOFTCAR >> >> >> tty_io.c also has a few and n_tty has a couple we'd want. >> >>> >>> would it be overkill to have a sysctl kernel.ttyioctlwhitelist.X where X >>> is one of the ioctls above? >> >> >> Why would anyone want to change the entries on that list >> > > Did you see Serge's proposed solution? I want us to not be talking past > each other. Serge proposed the following: > > | By default, nothing changes - you can use those on your own tty, need > | CAP_SYS_ADMIN against init_user_ns otherwise. > | > | Introduce a new CAP_TTY_PRIVILEGED. > | > | When may_push_chars is removed from the whitelist, you lose the > | ability to use TIOCSTI on a tty - even your own - if you do not have > | CAP_TTY_PRIVILEGED against the tty's user_ns. > > The question is how do you add/remove something from this whitelist? I > assume by add/remove we don't mean that you have to recompile your > kernel to change the whitelist! > > you earlier said you wanted the check to look like this: > > | if (!whitelisted(ioctl) && different_namespace && magic_flag) > > I want to know which namespace you are talking about here. Did you mean > user_namespace? (the namespace I added tracking for in the tty_struct) There are many ways to attempt to cure this problem. They some that are just wrong. Pushing stuff up to CAP_SYS_ADMIN is fairly much always wrong. Using a whitelisted solution does have a downside but to use some application that use TIOCSTI safely I have not had to push application to CAP_SYS_ADMIN. Another question due to the way the exploit work a broken TIOCSTI where push back could be something someone as CAP_SYS_ADMIN run. What I don't know if yet set when ever an application used TIOCSTI to push back chars back into input that this would set input to be flushed on tty disconnect or application termination would this break any applications. So it may be possible to allow applications to freely use TIOCSTI just make sure that anything an application has pushed back into input buffer cannot get to anything else. The thing to remember is most times when applications are controlling other applications they are not pushing data backwards on input.. Question I have is what is valid usage cases of TIOCSTI. Thinking grscecurity got away with pushing this up to CAP_SYS_ADMIN there may not be many. If there is no valid usage of TIOCSTI across applications there is no reason why TIOCSTI cannot be setup to automatically trigger input flushs to prevent TIOCSTI inserted data getting anywhere. . This could be like X11 and it huge number of features where large number were found that no one ever used just was created that way because it was though like it would be useful. My problem here is TIOCSTI might not need a flag at all. TIOCSTI functionality maybe in need of limitations particularly if TIOCSTI push back into input cross from one application to the next has no genuine application usage. So far no one has started that exploited TIOCSTI functionality exists in any genuine application as expected functionality. I cannot find example of where pushing back into input then going to background or dieing/exiting and having that pushed back input processed is done by any genuine application as expected functionality. That is something that could be limited if there is no genuine users and close the door without having to modify existing applications that don't expect to-do that. Its really simple to get focused in on quick fix to problems without asking is the behaviour even required. Peter Dolding
Re: [PATCH V3 1/2] powerpc/numa: Update CPU topology when VPHN enabled
Hi Michael, [auto build test ERROR on powerpc/next] [also build test ERROR on v4.12-rc3 next-20170602] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Michael-Bringmann/powerpc-numa-Update-CPU-topology-when-VPHN-enabled/20170527-052650 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next config: powerpc-cell_defconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=powerpc All errors (new ones prefixed by >>): >> arch/powerpc/mm/numa.c:47:12: error: 'topology_update_needed' defined but >> not used [-Werror=unused-variable] static int topology_update_needed; ^~ >> arch/powerpc/mm/numa.c:46:12: error: 'topology_inited' defined but not used >> [-Werror=unused-variable] static int topology_inited; ^~~ cc1: all warnings being treated as errors vim +/topology_update_needed +47 arch/powerpc/mm/numa.c 40 #include 41 #include 42 #include 43 #include 44 45 static int numa_enabled = 1; > 46 static int topology_inited; > 47 static int topology_update_needed; 48 49 static char *cmdline __initdata; 50 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v2 2/3] PCI: Enable PCIe Relaxed Ordering if supported
On 2017/6/4 2:19, Alexander Duyck wrote:
> On Fri, Jun 2, 2017 at 9:04 PM, Ding Tianhong wrote:
>> The PCIe Device Control Register use the bit 4 to indicate that
>> whether the device is permitted to enable relaxed ordering or not.
>> But relaxed ordering is not safe for some platform which could only
>> use strong write ordering, so devices are allowed (but not required)
>> to enable relaxed ordering bit by default.
>>
>> If a platform support relaxed ordering but does not enable it by
>> default, enable it in the PCIe configuration. This allows some device
>> to send TLPs with the relaxed ordering attributes set, which may
>> improve the performance.
>>
>> Signed-off-by: Ding Tianhong
>> ---
>> drivers/pci/pci.c | 42 ++
>> drivers/pci/probe.c | 11 +++
>> include/linux/pci.h | 3 +++
>> 3 files changed, 56 insertions(+)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index b01bd5b..f57a374 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -4878,6 +4878,48 @@ int pcie_set_mps(struct pci_dev *dev, int mps)
>> EXPORT_SYMBOL(pcie_set_mps);
>>
>> /**
>> + * pcie_set_relaxed_ordering - set PCI Express relexed ordering bit
>> + * @dev: PCI device to query
>> + *
>> + * If possible sets relaxed ordering
>> + */
>> +int pcie_set_relaxed_ordering(struct pci_dev *dev)
>> +{
>> + return pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
>> PCI_EXP_DEVCTL_RELAX_EN);
>> +}
>> +EXPORT_SYMBOL(pcie_set_relaxed_ordering);
>> +
>> +/**
>> + * pcie_clear_relaxed_ordering - clear PCI Express relexed ordering bit
>> + * @dev: PCI device to query
>> + *
>> + * If possible clear relaxed ordering
>> + */
>> +int pcie_clear_relaxed_ordering(struct pci_dev *dev)
>> +{
>> + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
>> PCI_EXP_DEVCTL_RELAX_EN);
>> +}
>> +EXPORT_SYMBOL(pcie_clear_relaxed_ordering);
>> +
>> +/**
>> + * pcie_get_relaxed_ordering - check PCI Express relexed ordering bit
>> + * @dev: PCI device to query
>> + *
>> + * Returns true if relaxed ordering is been set
>> + */
>> +int pcie_get_relaxed_ordering(struct pci_dev *dev)
>> +{
>> + u16 v;
>> +
>> + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v);
>> +
>> + return (v & PCI_EXP_DEVCTL_RELAX_EN) >> 4;
>> +}
>> +EXPORT_SYMBOL(pcie_get_relaxed_ordering);
>> +
>> +/**
>> + * pcie_set_mps - set PCI Express maximum payload size
>> +/**
>> * pcie_get_minimum_link - determine minimum link settings of a PCI device
>> * @dev: PCI device to query
>> * @speed: storage for minimum speed
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 19c8950..aeb22b5 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1701,6 +1701,16 @@ static void pci_configure_extended_tags(struct
>> pci_dev *dev)
>> PCI_EXP_DEVCTL_EXT_TAG);
>> }
>>
>> +static void pci_configure_relaxed_ordering(struct pci_dev *dev)
>> +{
>> + int ret;
>> +
>> + if (dev && (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING))
>
> So there is a minor issue here. The problem is this is only trying to
> modify relaxed ordering for the device itself. That isn't what we
> want. What we want is to modify it on all of the upstream port
> interfaces where there is something the path to the root complex that
> has an issue. So if the root complex has to set the
> NO_RELAXED_ORDERING flag on a root port, all of the interfaces below
> it that would be pushing traffic toward it should not have the relaxed
> ordering bit set.
>
> Also I am pretty sure this is a PCIe capability, not a PCI capability.
> You probably need to make sure you code is making this distinction
> which I don't know if it currently is. If you need an example of the
> kind of checks I am suggesting just take a look at
> pcie_configure_mps(). It is verifying the function is PCIe before
> attempting to make any updates. In your case you will probably also
> need to make sure there is a bus for you to walk up the chain of.
> Otherwise this shouldn't apply.
>
Yes, I miss the upstream ports and the pcie/pci capability, will check
the pcie_configure_mps() again and fix it, thanks.
>
>> + pcie_set_relaxed_ordering(dev);
>> + else
>> + pcie_clear_relaxed_ordering(dev);
>> +}
>
> Also I am not a fan of the way this is handled currently. If you don't
> have relaxed ordering set then you don't need to do anything else, if
> you do have it set but there is no bus to walk up you shouldn't change
> it, and if there is a bus to walk up and you find that the root
> complex on that bus has the NO_RELAXED_ORDERING set you should clear
> it. Right now this code seems to be enabling relaxed ordering if the
> NO_RELAXED_ORDERING flag is set.
>
I'm not very clear about this, I check the PCIe Standard, it said that:
Enable Relaxed Ordering – If this bit is set, the device is
permitted to set the Relaxed Ordering bit in the At
[PATCH 1/2] arm64: allwinner: a64: add DTSI file for SoPine SoM
From: Icenowy Zheng
SoPine is a SoM by Pine64, which have a gold finger compatible with the
slot of DDR3 SODIMM (signals are not compatible), and have an A64, an
AXP803, a LPDDR3 DRAM chip, a power led and a MicroSD slot on it.
The card detect pin of the MicroSD slot on the SoM is pulled down, which
makes it unusable; however, the slot is at the surface of the SoM that
is closed to the baseboard, so it's nearly impossible to hot-swap it,
thus I make it non-removable.
Signed-off-by: Icenowy Zheng
---
.../boot/dts/allwinner/sun50i-a64-sopine.dtsi | 65 ++
1 file changed, 65 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
new file mode 100644
index ..475518b031dd
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
@@ -0,0 +1,65 @@
+/*
+ * Copyright (c) 2017 Icenowy Zheng
+ *
+ * Based on sun50i-a64-pine64.dts, which is:
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun50i-a64.dtsi"
+
+/ {
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ non-removable;
+ disable-wp;
+ bus-width = <4>;
+ status = "okay";
+};
--
2.12.2
[PATCH 2/2] arm64: allwinner: a64: add device tree for SoPine with baseboard
From: Icenowy Zheng
Pine64 have made an official baseboard when SoPine SoM is out.
The official baseboard is like the original Pine64 -- but with SD card
slot replaced with Pine64's eMMC module slot.
Add a device tree for SoPine with the baseboard.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-a64-sopine-baseboard.dts | 126 +
2 files changed, 127 insertions(+)
create mode 100644
arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index 546720096aef..e7d54906453e 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,5 +1,6 @@
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
new file mode 100644
index ..17eb1cc5bf6b
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
@@ -0,0 +1,126 @@
+/*
+ * Copyright (c) 2017 Icenowy Zheng
+ *
+ * Based on sun50i-a64-pine64.dts, which is:
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-sopine.dtsi"
+
+/ {
+ model = "SoPine with baseboard";
+ compatible = "pine64,sopine-baseboard", "pine64,sopine",
+"allwinner,sun50i-a64";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc1v8: vcc1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ status = "okay";
+};
+
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ vqmmc-supply = <®_vcc1v8>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-hw-reset;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay"
Re: [RFC 0/3] WhiteEgret LSM module
On Thu, Jun 1, 2017 at 1:35 AM, Serge E. Hallyn wrote: > Quoting Casey Schaufler (ca...@schaufler-ca.com): >> >> >> On 5/31/2017 3:59 AM, Peter Dolding wrote: >> > ... >> > >> > Like you see here in Australian government policy there is another >> > thing called whitelisted. >> > https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm >> > Matthew Garrett you might want to call IMA whitelisting Australian >> > government for one does not agree. IMA is signed. The difference >> > between signed and white-listed is you might have signed a lot more >> > than what a particular system is white-listed to allowed used. >> > >> To be clear, I'm all for a security module to support this policy. >> As the explicit requirement is for a whitelist, as opposed to allowing >> for a properly configured system*, you can't use any of the existing >> technologies to meet it. This kind of thing** is why we have a LSM >> infrastructure. >> >> Unfortunately, the implementation proposed has very serious issues. >> You can't do access control from userspace. You can't count on >> identifying programs strictly by pathname. It's much more complicated >> than it needs to be for the task. >> >> Suggestion: >> >> Create an security module that looks for the attribute >> >> security.WHITELISTED > > Bonus, you can have EVM verify the validity of these xattrs, and > IMA verify the interity of the file itself. Complete fail. You have to think of a whitelist as a list you give to a security at a gate. Shot-gunned all over the file system that you have to search down what is approved is not acceptable. I should be more clear you need a whitelist file to tick the box. Where you can open up 1 file and see everything that is on the approved list. Same with blacklist. Think of it like a list of invited guests given to a security guard at a door. You can check who is invited by look at that list. Attribute is like saying if the person has X id let them in and going to the guard at the door to see who is let in is not going to help you. Of course just because the guard at door is letting people on the list in does not mean they are not checking ids as well. This is not an either or issue this is an add a feature. So whitelist file and Attribute in production usage function way differently. You don't want to have to scan a complete filesystem all the time looking for stray set attributes. Whitelist and Blacklisting fits into IMA not LSM really.Because you need to be able to use other LSM at the same time as white/blacklists. EVM and attributes they are so easy to use that implement whitelist/blacklist files has not be done. Including means to sign whitelist files to prevent modification when required. So what both of you are suggest is not the right item to tick the box to claim Linux has whitelist support. Linux has hacks to implement whitelist support not properly whitelist support that is functional in the right way. Whitelist functional in the right way look in 1 location know what is set. Also IMA support for containers is kind required supporting whitelist/blacklist files because setting everything into attribute can become very impractical. So this is something that is missing. Peter Dolding
Re: [RFC 0/3] WhiteEgret LSM module
On Thu, Jun 1, 2017 at 1:36 AM, Mehmet Kayaalp wrote: > >> On May 31, 2017, at 6:59 AM, Peter Dolding wrote: >> >> Number 1 we need to split the idea of signed and whitelisted. IMA is >> signed should not be confused with white-listed.You will find >> policies stating whitelist and signed as two different things. > > IMA-appraisal can do both. If the securtiy.ima extended attribute > of the file is a hash and not a signature, then it is whitelisting. This this point you straight up fail. This is no long classes a whitelist. Its now an extended attribute checksum. IMA with proper whitelist support were whitelist is a file allows IMA to have hashs and so on stored in that file so removing the need for the filesystem where IMA being used to have extended attributes. Second for this is being able to open up 1 file and see what is approved. > >> Like you see here in Australian government policy there is another >> thing called whitelisted. >> https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm >> Matthew Garrett you might want to call IMA whitelisting Australian >> government for one does not agree. IMA is signed. The difference >> between signed and white-listed is you might have signed a lot more >> than what a particular system is white-listed to allowed used. > > I doubt the Australian government is an authority on Linux features. > IMA-appraisal can be set to "fix" mode with a boot parameter. If the > policy covers what you want to whitelist (e.g. files opened by user x), > and then when those files are accessed, the kernel writes out the hash. > Then, you can switch to "enforce" mode to allow only files with hashes. Question does this feature support booting the system in different modes giving different accessible files. The feature says whitelist but is fact to tick the box is lists. So booted into standard mode has one lot of applications and booted into repair mode has another lot of applications and so on with this being achieved by choosing different whitelist files at boot. > > Also, you can achieve the same thing by signing all whitelisted > files and add the certificate to .ima keyring and throwing away the > signing key. This here is signed nothing to-do with whitelist.This is using signing to hack round not having a proper whitelist feature so this can never ticks the box. > >> The feature need to include in it name whitelisting or just like the >> Australian Department of Defence other parties will mark Linux has not >> having this feature. > > I guess we need to advertise IMA-appraisal better. They have looked that and it fails. Because IMA currently is lacking the feature. I do see that whitelist and blacklist file support added to IMA so IMA does not need extended attribute file systems and for those who want all the setting in one file would be a good thing. UUID of the file system could be included in path to file in whitelist. > >> Whitelist is program name/path and checksum/s. If the file any more >> than that is now not a Whitelist but a Security Policy Enforcement or >> signing. Whitelist and blacklists are meant to be simple things. >> This is also why IMA fails and is signed to too complete to be a basic >> Whitelist. > > When you work out all the little details, you arrive at IMA-appraisal. > You have to consider how the scheme is bootstrapped and how it > is protected against the root. IMA-appraisal either relies on a boot > parameter and write-once policy, or the trusted keyrings. > Here you have gone wrong. You are presume whitelist has to be protected against root. A signed whitelist does have to be protected against root. Unsigned whitelist in fact being alterable by those with privilege is expected.. You don't have firewall rules always protected against root right. Unsigned whitelists are in the same camp. Also other mistakes is when they are looking for whitelist feature they are also looking for blacklist feature. IMA features need to apply just as much to containers as they do to the complete system. This is where things get tricky. Putting entries in filesystem xattr for every service you have risks running you out of file system xattr space. >From my point view the missing system wide whitelist and blacklist file support is a defect of IMA that is not design at this stage to be able to function without filesystem xattr as soon as remove the means to use xattr design IMA you are forced to implement whitelist file at least.. Also I see it as a weakness in IMA that it cannot be done on a per container base and this is also mostly likely due to over file system dependence. I am not saying that IMA xattr usage has to be removed but it should not be the only option IMA has. Peter Dolding
Re: [PATCH 1/1] Sealable memory support
Hi Igor,
[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.12-rc3 next-20170602]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/Sealable-memory-support/20170522-163525
base: git://git.cmpxchg.org/linux-mmotm.git master
config: i386-randconfig-n0-06032349 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
mm//smalloc.c: In function 'smalloc_seal_set':
>> mm//smalloc.c:135:4: error: implicit declaration of function 'set_memory_ro'
>> [-Werror=implicit-function-declaration]
set_memory_ro((unsigned long)node,
^
>> mm//smalloc.c:138:4: error: implicit declaration of function 'set_memory_rw'
>> [-Werror=implicit-function-declaration]
set_memory_rw((unsigned long)node,
^
cc1: some warnings being treated as errors
vim +/set_memory_ro +135 mm//smalloc.c
129 mutex_unlock(&pool->lock);
130 return;
131 }
132 list_for_each(pos, &pool->list) {
133 node = list_entry(pos, struct smalloc_node, list);
134 if (seal == SMALLOC_SEALED)
> 135 set_memory_ro((unsigned long)node,
136get_node_pages_nr(node));
137 else if (seal == SMALLOC_UNSEALED)
> 138 set_memory_rw((unsigned long)node,
139get_node_pages_nr(node));
140 }
141 pool->seal = seal;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH net-next v10 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
This is a defense-in-depth measure in response to bugs like
4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). There's
not only a potential overflow of sglist items, but also a stack overflow
potential, so we fix this by limiting the amount of recursion this function
is allowed to do. Not actually providing a bounded base case is a future
disaster that we can easily avoid here.
As a small matter of house keeping, we take this opportunity to move the
documentation comment over the actual function the documentation is for.
While this could be implemented by using an explicit stack of skbuffs,
when implementing this, the function complexity increased considerably,
and I don't think such complexity and bloat is actually worth it. So,
instead I built this and tested it on x86, x86_64, ARM, ARM64, and MIPS,
and measured the stack usage there. I also reverted the recent MIPS
changes that give it a separate IRQ stack, so that I could experience
some worst-case situations. I found that limiting it to 24 layers deep
yielded a good stack usage with room for safety, as well as being much
deeper than any driver actually ever creates.
Signed-off-by: Jason A. Donenfeld
Cc: Steffen Klassert
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: David Howells
Cc: Sabrina Dubroca
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
---
include/linux/skbuff.h | 8 +++
net/core/skbuff.c | 65 --
2 files changed, 46 insertions(+), 27 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 45a59c1e0cc7..d460a4cbda1c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -953,10 +953,10 @@ struct sk_buff *skb_realloc_headroom(struct sk_buff *skb,
unsigned int headroom);
struct sk_buff *skb_copy_expand(const struct sk_buff *skb, int newheadroom,
int newtailroom, gfp_t priority);
-int skb_to_sgvec_nomark(struct sk_buff *skb, struct scatterlist *sg,
- int offset, int len);
-int skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset,
-int len);
+int __must_check skb_to_sgvec_nomark(struct sk_buff *skb, struct scatterlist
*sg,
+int offset, int len);
+int __must_check skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg,
+ int offset, int len);
int skb_cow_data(struct sk_buff *skb, int tailbits, struct sk_buff **trailer);
int skb_pad(struct sk_buff *skb, int pad);
#define dev_kfree_skb(a) consume_skb(a)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 780b7c1563d0..bba33cf4f7cd 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3508,24 +3508,18 @@ void __init skb_init(void)
NULL);
}
-/**
- * skb_to_sgvec - Fill a scatter-gather list from a socket buffer
- * @skb: Socket buffer containing the buffers to be mapped
- * @sg: The scatter-gather list to map into
- * @offset: The offset into the buffer's contents to start mapping
- * @len: Length of buffer space to be mapped
- *
- * Fill the specified scatter-gather list with mappings/pointers into a
- * region of the buffer space attached to a socket buffer.
- */
static int
-__skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int
len)
+__skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int
len,
+ unsigned int recursion_level)
{
int start = skb_headlen(skb);
int i, copy = start - offset;
struct sk_buff *frag_iter;
int elt = 0;
+ if (unlikely(recursion_level >= 24))
+ return -EMSGSIZE;
+
if (copy > 0) {
if (copy > len)
copy = len;
@@ -3544,6 +3538,8 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist
*sg, int offset, int len)
end = start + skb_frag_size(&skb_shinfo(skb)->frags[i]);
if ((copy = end - offset) > 0) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+ if (unlikely(elt && sg_is_last(&sg[elt - 1])))
+ return -EMSGSIZE;
if (copy > len)
copy = len;
@@ -3558,16 +3554,22 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist
*sg, int offset, int len)
}
skb_walk_frags(skb, frag_iter) {
- int end;
+ int end, ret;
WARN_ON(start > offset + len);
end = start + frag_iter->len;
if ((copy = end - offset) > 0) {
+ if (unlikely(elt && sg_is_last(&sg[elt - 1])))
+ return -EMSGSIZE;
+
if (copy > len)
copy = len;
- elt += __skb_to_sgvec(frag_iter, sg+elt, offset - st
[PATCH net-next v10 2/5] ipsec: check return value of skb_to_sgvec always
Signed-off-by: Jason A. Donenfeld
Cc: Steffen Klassert
Cc: Herbert Xu
Cc: "David S. Miller"
---
net/ipv4/ah4.c | 8 ++--
net/ipv4/esp4.c | 20 +---
net/ipv6/ah6.c | 8 ++--
net/ipv6/esp6.c | 20 +---
4 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 22377c8ff14b..e8f862358518 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -220,7 +220,9 @@ static int ah_output(struct xfrm_state *x, struct sk_buff
*skb)
ah->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.low);
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
@@ -393,7 +395,9 @@ static int ah_input(struct xfrm_state *x, struct sk_buff
*skb)
skb_push(skb, ihl);
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 93322f895eab..d815d1755473 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -377,9 +377,11 @@ int esp_output_tail(struct xfrm_state *x, struct sk_buff
*skb, struct esp_info *
esp->esph = esph;
sg_init_table(sg, esp->nfrags);
- skb_to_sgvec(skb, sg,
-(unsigned char *)esph - skb->data,
-assoclen + ivlen + esp->clen + alen);
+ err = skb_to_sgvec(skb, sg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + esp->clen + alen);
+ if (unlikely(err < 0))
+ goto error;
if (!esp->inplace) {
int allocsize;
@@ -403,9 +405,11 @@ int esp_output_tail(struct xfrm_state *x, struct sk_buff
*skb, struct esp_info *
spin_unlock_bh(&x->lock);
sg_init_table(dsg, skb_shinfo(skb)->nr_frags + 1);
- skb_to_sgvec(skb, dsg,
-(unsigned char *)esph - skb->data,
-assoclen + ivlen + esp->clen + alen);
+ err = skb_to_sgvec(skb, dsg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + esp->clen + alen);
+ if (unlikely(err < 0))
+ goto error;
}
if ((x->props.flags & XFRM_STATE_ESN))
@@ -690,7 +694,9 @@ static int esp_input(struct xfrm_state *x, struct sk_buff
*skb)
esp_input_set_header(skb, seqhi);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ err = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out;
skb->ip_summed = CHECKSUM_NONE;
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index dda6035e3b84..755f38271dd5 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -423,7 +423,9 @@ static int ah6_output(struct xfrm_state *x, struct sk_buff
*skb)
ah->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.low);
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
@@ -606,7 +608,9 @@ static int ah6_input(struct xfrm_state *x, struct sk_buff
*skb)
ip6h->hop_limit = 0;
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 1fe99ba8066c..2ede4e459c4e 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -346,9 +346,11 @@ int esp6_output_tail(struct xfrm_state *x, struct sk_buff
*skb, struct esp_info
esph = esp_output_set_esn(skb, x, ip_esp_hdr(skb), seqhi);
sg_init_table(sg, esp->nfrags);
- skb_to_sgvec(skb, sg,
-(unsigned char *)esph - skb->data,
-assoclen + ivlen + esp->clen + alen);
+ err = skb_to_sgvec(skb, sg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + esp->clen + alen);
+ if (unlikely(err < 0))
+ goto error;
if (!esp->inplace) {
int allocsize;
@@ -372,9 +374,11 @@ int esp6_
[PATCH net-next v10 3/5] rxrpc: check return value of skb_to_sgvec always
Signed-off-by: Jason A. Donenfeld
Acked-by: David Howells
---
net/rxrpc/rxkad.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 1bb9b2ccc267..29fe20ad04aa 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -227,7 +227,9 @@ static int rxkad_secure_packet_encrypt(const struct
rxrpc_call *call,
len &= ~(call->conn->size_align - 1);
sg_init_table(sg, nsg);
- skb_to_sgvec(skb, sg, 0, len);
+ err = skb_to_sgvec(skb, sg, 0, len);
+ if (unlikely(err < 0))
+ goto out;
skcipher_request_set_crypt(req, sg, sg, len, iv.x);
crypto_skcipher_encrypt(req);
@@ -324,7 +326,7 @@ static int rxkad_verify_packet_1(struct rxrpc_call *call,
struct sk_buff *skb,
bool aborted;
u32 data_size, buf;
u16 check;
- int nsg;
+ int nsg, ret;
_enter("");
@@ -342,7 +344,9 @@ static int rxkad_verify_packet_1(struct rxrpc_call *call,
struct sk_buff *skb,
goto nomem;
sg_init_table(sg, nsg);
- skb_to_sgvec(skb, sg, offset, 8);
+ ret = skb_to_sgvec(skb, sg, offset, 8);
+ if (unlikely(ret < 0))
+ return ret;
/* start the decryption afresh */
memset(&iv, 0, sizeof(iv));
@@ -409,7 +413,7 @@ static int rxkad_verify_packet_2(struct rxrpc_call *call,
struct sk_buff *skb,
bool aborted;
u32 data_size, buf;
u16 check;
- int nsg;
+ int nsg, ret;
_enter(",{%d}", skb->len);
@@ -434,7 +438,12 @@ static int rxkad_verify_packet_2(struct rxrpc_call *call,
struct sk_buff *skb,
}
sg_init_table(sg, nsg);
- skb_to_sgvec(skb, sg, offset, len);
+ ret = skb_to_sgvec(skb, sg, offset, len);
+ if (unlikely(ret < 0)) {
+ if (sg != _sg)
+ kfree(sg);
+ return ret;
+ }
/* decrypt from the session key */
token = call->conn->params.key->payload.data[0];
--
2.13.0
[PATCH net-next v10 4/5] macsec: check return value of skb_to_sgvec always
Signed-off-by: Jason A. Donenfeld
Cc: Sabrina Dubroca
---
drivers/net/macsec.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 91642fd87cd1..b79513b8322f 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -740,7 +740,12 @@ static struct sk_buff *macsec_encrypt(struct sk_buff *skb,
macsec_fill_iv(iv, secy->sci, pn);
sg_init_table(sg, ret);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ ret = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(ret < 0)) {
+ macsec_txsa_put(tx_sa);
+ kfree_skb(skb);
+ return ERR_PTR(ret);
+ }
if (tx_sc->encrypt) {
int len = skb->len - macsec_hdr_len(sci_present) -
@@ -947,7 +952,11 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
macsec_fill_iv(iv, sci, ntohl(hdr->packet_number));
sg_init_table(sg, ret);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ ret = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(ret < 0)) {
+ kfree_skb(skb);
+ return ERR_PTR(ret);
+ }
if (hdr->tci_an & MACSEC_TCI_E) {
/* confidentiality: ethernet + macsec header
--
2.13.0
[PATCH net-next v10 5/5] virtio_net: check return value of skb_to_sgvec always
Signed-off-by: Jason A. Donenfeld
Reviewed-by: Sergei Shtylyov
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
---
drivers/net/virtio_net.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 3e9246cc49c3..57763d30cabb 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1150,7 +1150,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff
*skb)
struct virtio_net_hdr_mrg_rxbuf *hdr;
const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
struct virtnet_info *vi = sq->vq->vdev->priv;
- unsigned num_sg;
+ int num_sg;
unsigned hdr_len = vi->hdr_len;
bool can_push;
@@ -1177,11 +1177,16 @@ static int xmit_skb(struct send_queue *sq, struct
sk_buff *skb)
if (can_push) {
__skb_push(skb, hdr_len);
num_sg = skb_to_sgvec(skb, sq->sg, 0, skb->len);
+ if (unlikely(num_sg < 0))
+ return num_sg;
/* Pull header back to avoid skew in tx bytes calculations. */
__skb_pull(skb, hdr_len);
} else {
sg_set_buf(sq->sg, hdr, hdr_len);
- num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
+ num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len);
+ if (unlikely(num_sg < 0))
+ return num_sg;
+ num_sg++;
}
return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC);
}
--
2.13.0
[PATCH net-next v10 0/5] Avoiding stack overflow in skb_to_sgvec
Changes v9->v10: - Spaces to tabs on one line. - Added some acked-by, reviewed-by lines. Since we're down to only cleaning up things like spaces-to-tabs, I believe we can merge this patch series. David - would you put this in net-next, please? The recent bug with macsec and historical one with virtio have indicated that letting skb_to_sgvec trounce all over an sglist without checking the length is probably a bad idea. And it's not necessary either: an sglist already explicitly marks its last item, and the initialization functions are diligent in doing so. Thus there's a clear way of avoiding future overflows. So, this patchset, from a high level, makes skb_to_sgvec return a potential error code, and then adjusts all callers to check for the error code. There are two situations in which skb_to_sgvec might return such an error: 1) When the passed in sglist is too small; and 2) When the passed in skbuff is too deeply nested. So, the first patch in this series handles the issues with skb_to_sgvec directly, and the remaining ones then handle the call sites. Jason A. Donenfeld (5): skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow ipsec: check return value of skb_to_sgvec always rxrpc: check return value of skb_to_sgvec always macsec: check return value of skb_to_sgvec always virtio_net: check return value of skb_to_sgvec always drivers/net/macsec.c | 13 -- drivers/net/virtio_net.c | 9 +-- include/linux/skbuff.h | 8 +++--- net/core/skbuff.c| 65 +++- net/ipv4/ah4.c | 8 -- net/ipv4/esp4.c | 20 +-- net/ipv6/ah6.c | 8 -- net/ipv6/esp6.c | 20 +-- net/rxrpc/rxkad.c| 19 ++ 9 files changed, 116 insertions(+), 54 deletions(-) -- 2.13.0
Re: [PATCH net] net: ping: do not abuse udp_poll()
On Sun, Jun 4, 2017 at 1:29 AM, Eric Dumazet wrote: > The problem is that ping sockets should not use udp_poll() in the first > place, and recent changes in UDP stack finally exposed this old bug. Acked-By: Lorenzo Colitti Tested-By: Lorenzo Colitti
Re: [PATCH v4 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver
On Saturday, June 3, 2017 12:57:50 PM CEST Varadarajan Narayanan wrote: > +- function: > + Usage: required > + Value type: > + Definition: Specify the alternative function to be configured for the > + specified pins. Functions are only valid for gpio pins. > + Valid values are: > + atest_char, atest_char0, atest_char1, atest_char2, > + atest_char3, audio_rxbclk, audio_rxd, audio_rxfsync, > + audio_rxmclk, audio_txbclk, audio_txd, audio_txfsync, > + audio_txmclk, blsp0_i2c, blsp0_spi, blsp0_uart, blsp1_i2c, > + blsp1_spi, blsp1_uart, blsp2_i2c, blsp2_spi, blsp2_uart, > + blsp3_i2c, blsp3_spi, blsp3_spi0, blsp3_spi1, blsp3_spi2, > + blsp3_spi3, blsp3_uart, blsp4_i2c0, blsp4_i2c1, > blsp4_spi0, > + blsp4_spi1, blsp4_uart0, blsp4_uart1, blsp5_i2c, > blsp5_spi, > + blsp5_uart, burn0, burn1, cri_trng, cri_trng0, cri_trng1, > + cxc0, cxc1, dbg_out, gcc_plltest, gcc_tlmm, gpio, ldo_en, > + ldo_update, led0, led1, led2, mac0_sa0, mac0_sa1, > mac1_sa0, > + mac1_sa1, mac1_sa2, mac1_sa3, mac2_sa0, mac2_sa1, mdc, > + mdio, NA, pcie0_clk, pcie0_rst, pcie0_wake, pcie1_clk, > + pcie1_rst, pcie1_wake, pcm_drx, pcm_dtx, pcm_fsync, > + pcm_pclk, pcm_zsi0, pcm_zsi1, prng_rosc, pta1_0, pta1_1, > + pta1_2, pta2_0, pta2_1, pta2_2, pwm0, pwm1, pwm2, pwm3, > + qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, > + qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, > + qdss_cti_trig_out_a0, qdss_cti_trig_out_a1, > + qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, > + qdss_traceclk_a, qdss_traceclk_b, qdss_tracectl_a, > + qdss_tracectl_b, qdss_tracedata_a, qdss_tracedata_b, > + qpic, rx0, rx1, rx2, sd_card, sd_write, tsens_max, wci2a, > + wci2b, wci2c, wci2d, NA The "NA" function is listed twice. It should be there at all.
Re: [PATCH v9 2/4] arm64: dts: hisi: add kirin pcie node
Hi Xiaowei, [auto build test ERROR on pci/next] [also build test ERROR on v4.12-rc3 next-20170602] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Xiaowei-Song/add-PCIe-driver-for-Kirin-PCIe/20170531-182118 base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next config: arm64-allnoconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 All errors (new ones prefixed by >>): >> Error: arch/arm64/boot/dts/hisilicon/hi3660.dtsi:180.24-25 syntax error >> FATAL ERROR: Unable to parse input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete
On 3 June 2017 at 18:54, Jeffrey Walton wrote: > On Sat, Jun 3, 2017 at 5:45 PM, Sandy Harris wrote: >> ... >> Of course this will fail on systems with no high-res timer. Are there >> still some of those? It might be done in about 1000 times as long on a >> system that lacks the realtime library's nanosecond timer but has the >> Posix standard microsecond timer, implying a delay time in the >> milliseconds. Would that be acceptable in those cases? > > A significant portion of the use cases should include mobile devices. > Device sales outnumbered desktop and server sales several years ago. > > Many devices are sensor rich. Even the low-end ones come with > accelorometers for gaming. A typical one has 3 or 4 sensors, and > higher-end ones have 7 or 8 sensors. An Evo 4G has 7 of them. > > There's no wanting for entropy in many of the use cases. The thing > that is lacking seems to be taking advantage of it. > > Jeff Hardware random number generator support is also standard on even low-end mobile devices. The Linux kernel now knows to feed some of the entropy from those hardware random generators into the kernel CSPRNG when the driver is initialized but that doesn't happen until fairly late in the kernel's boot process. The sensors present the same issue. They aren't available when the kernel starts needing entropy for features like SSP and KASLR or other early boot uses, unlike RDRAND/RDSEED on modern x86_64 CPUs. For userspace, Android's init system blocks until a certain amount of entropy is obtained from one for the kernel CSPRNG. It's possible for there to be no hwrandom but I think that's very rare now since the standard SoCs used everywhere have it available. The device vendor would probably need to go out of the way to break it. Android also regularly saves a persistent random seed and restores it on boot. It also mixes in entropy from the hardware generator regularly since the kernel didn't know how to do that before, just like it didn't know how to grab any initial entropy from the hardware generator. I don't think it's worth worrying too much about mobile. Slimmer embedded devices that probably don't even save / restore a seed in many cases or generate keys on first boot before that helps are the real issue. At least if you're not focused on KASLR and other early probabilistic kernel exploit mitigations where there's a lack of a way to get entropy in early boot right now unless the bootloader helps.
Re: [PATCH] staging: rtl8723bs: fix a couple of spelling mistakes
On Sat, 2017-06-03 at 23:21 +0100, Colin King wrote:
> Replace cant with cannot, argumetns with arguments and
> add line break to overly long DBG_871X statement.
[]
> diff --git a/drivers/staging/rtl8723bs/hal/hal_com.c
> b/drivers/staging/rtl8723bs/hal/hal_com.c
[]
> @@ -26,7 +26,7 @@ u8 rtw_hal_data_init(struct adapter *padapter)
> padapter->hal_data_sz = sizeof(struct hal_com_data);
> padapter->HalData = vzalloc(padapter->hal_data_sz);
> if (padapter->HalData == NULL) {
> - DBG_8192C("cant not alloc memory for HAL DATA\n");
> + DBG_8192C("cannot not alloc memory for HAL DATA\n");
"cannot not" does not make sense.
[PATCH 4/4] Staging: ccree: cc_crypto_ctx.h: Added * on subsequent lines of a comment block
Added *'s on subsequent lines of a comment block to fix coding style issues.
Signed-off-by: srishti sharma
---
drivers/staging/ccree/cc_crypto_ctx.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h
b/drivers/staging/ccree/cc_crypto_ctx.h
index 03164624..a8747d5 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -281,9 +281,9 @@ struct drv_ctx_aead {
/* Get the address of a @member within a given @ctx address
- @ctx: The context address
- @type: Type of context structure
- @member: Associated context field */
+ * @ctx: The context address
+ * @type: Type of context structure
+ * @member: Associated context field */
#define GET_CTX_FIELD_ADDR(ctx, type, member) (ctx + offsetof(type, member))
#endif /* _CC_CRYPTO_CTX_H_ */
--
2.7.4
[PATCH 3/4] Staging: ccree: cc_crypto_ctx.h: Fixed * alignment issues in a comment block
Fixed the alignment of * in a comment block.
Signed-off-by: srishti sharma
---
drivers/staging/ccree/cc_crypto_ctx.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h
b/drivers/staging/ccree/cc_crypto_ctx.h
index 27a5914..03164624 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -242,9 +242,9 @@ struct drv_ctx_cipher {
u32 key_size; /* numeric value in bytes */
u32 data_unit_size; /* required for XTS */
/* block_state is the AES engine block state.
- * It is used by the host to pass IV or counter at initialization.
- * It is used by SeP for intermediate block chaining state and for
- * returning MAC algorithms results. */
+* It is used by the host to pass IV or counter at initialization.
+* It is used by SeP for intermediate block chaining state and for
+* returning MAC algorithms results. */
u8 block_state[CC_AES_BLOCK_SIZE];
u8 key[CC_AES_KEY_SIZE_MAX];
u8 xex_key[CC_AES_KEY_SIZE_MAX];
--
2.7.4
[PATCH 2/4] Staging: ccree: cc_crypto_ctx.h: Fixed trailing */ issue in a comment block
Fixed trailing */ style issue in a block comment.
Signed-off-by: srishti sharma
---
drivers/staging/ccree/cc_crypto_ctx.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h
b/drivers/staging/ccree/cc_crypto_ctx.h
index 6ee51b8..27a5914 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -218,8 +218,10 @@ struct drv_ctx_hash {
CC_DIGEST_SIZE_MAX];
};
-/* drv_ctx_hmac should have the same structure as drv_ctx_hash except
- * k0, k0_size fields */
+/*
+ * drv_ctx_hmac should have the same structure as drv_ctx_hash except
+ * k0, k0_size fields
+ */
struct drv_ctx_hmac {
enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_HMAC */
enum drv_hash_mode mode;
@@ -285,4 +287,3 @@ struct drv_ctx_aead {
#define GET_CTX_FIELD_ADDR(ctx, type, member) (ctx + offsetof(type, member))
#endif /* _CC_CRYPTO_CTX_H_ */
-
--
2.7.4
[PATCH 1/4] Staging: ccree: cc_crypto_ctx.h: Added * on subsequent lines of a comment block.
Added * on subsequent lines of a comment block.
Signed-off-by: srishti sharma
---
drivers/staging/ccree/cc_crypto_ctx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h
b/drivers/staging/ccree/cc_crypto_ctx.h
index ac39d34..6ee51b8 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -219,7 +219,7 @@ struct drv_ctx_hash {
};
/* drv_ctx_hmac should have the same structure as drv_ctx_hash except
- k0, k0_size fields */
+ * k0, k0_size fields */
struct drv_ctx_hmac {
enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_HMAC */
enum drv_hash_mode mode;
--
2.7.4
[GIT PULL] Please pull NFS client bugfixes for Linux 4.12
Hi Linus, The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d: Linux 4.12-rc2 (2017-05-21 19:30:23 -0700) are available in the git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.12-2 for you to fetch changes up to 4f253e1eb628f5adf7ca4f43aab4bbb1bfffa081: nfs: Mark unnecessarily extern functions as static (2017-06-03 16:06:38 -0400) NFS client bugfixes for Linux 4.12 Bugfixes include: - Fix a typo in commit e092693443b that breaks copy offload - Fix the connect error propagation in xs_tcp_setup_socket() - Fix a lock leak in nfs40_walk_client_list - Verify that pNFS requests lie within the offset range of the layout segment. Benjamin Coddington (1): pnfs: Fix the check for requests in range of layout segment Dan Carpenter (1): pNFS/flexfiles: missing error code in ff_layout_alloc_lseg() Jan Kara (1): nfs: Mark unnecessarily extern functions as static Markus Elfring (1): xprtrdma: Delete an error message for a failed memory allocation in xprt_rdma_bc_setup() NeilBrown (1): SUNRPC: ensure correct error is reported by xs_tcp_setup_socket() Olga Kornievskaia (1): NFS fix COMMIT after COPY Trond Myklebust (1): NFSv4.0: Fix a lock leak in nfs40_walk_client_list fs/nfs/flexfilelayout/flexfilelayout.c | 1 + fs/nfs/internal.h | 2 -- fs/nfs/nfs42proc.c | 2 +- fs/nfs/nfs4client.c| 1 - fs/nfs/pnfs.c | 25 + fs/nfs/pnfs.h | 10 ++ fs/nfs/super.c | 5 +++-- net/sunrpc/xprtrdma/backchannel.c | 6 ++ net/sunrpc/xprtsock.c | 7 ++- 9 files changed, 40 insertions(+), 19 deletions(-) -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.mykleb...@primarydata.com
[PATCH 0/4] Fixed comment coding style issues.
This patchset contains a series of comment coding style issues fixes. srishti sharma (4): Staging: ccree: cc_crypto_ctx.h: Added * on subsequent lines of a comment block. Staging: ccree: cc_crypto_ctx.h: Fixed trailing */ issue in a comment block Staging: ccree: cc_crypto_ctx.h: Fixed * alignment issues in a comment block Staging: ccree: cc_crypto_ctx.h: Added * on subsequent lines of a comment block drivers/staging/ccree/cc_crypto_ctx.h | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) -- 2.7.4
[PATCH][V2] staging: ccree: fix spelling mistake: "chanined" -> "chained"
From: Colin Ian King
Trivial fix to spelling mistake in SSI_LOG_ERR message
Signed-off-by: Colin Ian King
---
drivers/staging/ccree/ssi_buffer_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 04515e70d2d3..379eecf85ba1 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -156,7 +156,7 @@ static unsigned int ssi_buffer_mgr_get_sgl_nents(
unsigned int nents = 0;
while (nbytes != 0) {
if (sg_is_chain(sg_list)) {
- SSI_LOG_ERR("Unexpected chanined entry "
+ SSI_LOG_ERR("Unexpected chained entry "
"in sg (entry =0x%X) \n", nents);
BUG();
}
--
2.11.0
[PATCH] taging: ccree: fix spelling mistake: "chanined" -> "chained"
From: Colin Ian King
Trivial fix to spelling mistake in SSI_LOG_ERR message
Signed-off-by: Colin Ian King
---
drivers/staging/ccree/ssi_buffer_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 04515e70d2d3..379eecf85ba1 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -156,7 +156,7 @@ static unsigned int ssi_buffer_mgr_get_sgl_nents(
unsigned int nents = 0;
while (nbytes != 0) {
if (sg_is_chain(sg_list)) {
- SSI_LOG_ERR("Unexpected chanined entry "
+ SSI_LOG_ERR("Unexpected chained entry "
"in sg (entry =0x%X) \n", nents);
BUG();
}
--
2.11.0
Re: [PATCH V1 2/2] pwm: pwm-qti-lpg: Add PWM driver for QTI LPG module
Hi Fenglin,
[auto build test ERROR on j.anaszewski-leds/for-next]
[also build test ERROR on v4.12-rc3 next-20170602]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/fenglinw-codeaurora-org/leds-leds-qti-rgb-Add-LED-driver-for-QTI-TRI_LED-module/20170531-153634
base:
https://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git
for-next
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All errors (new ones prefixed by >>):
drivers/pwm/pwm-qti-lpg.c: In function 'qti_lpg_pwm_dbg_show':
>> drivers/pwm/pwm-qti-lpg.c:428:4: error: implicit declaration of function
>> 'seq_printf' [-Werror=implicit-function-declaration]
seq_printf(s, "LPG %d is requested by %s\n",
^
>> drivers/pwm/pwm-qti-lpg.c:437:4: error: implicit declaration of function
>> 'seq_puts' [-Werror=implicit-function-declaration]
seq_puts(s, " enabled\n");
^
cc1: some warnings being treated as errors
vim +/seq_printf +428 drivers/pwm/pwm-qti-lpg.c
422 if (lpg == NULL) {
423 dev_err(pwm_chip->dev, "lpg not found\n");
424 return;
425 }
426
427 if (test_bit(PWMF_REQUESTED, &pwm->flags)) {
> 428 seq_printf(s, "LPG %d is requested by %s\n",
429 lpg->lpg_idx + 1, pwm->label);
430 } else {
431 seq_printf(s, "LPG %d is free\n",
432 lpg->lpg_idx + 1);
433 continue;
434 }
435
436 if (pwm_is_enabled(pwm)) {
> 437 seq_puts(s, " enabled\n");
438 } else {
439 seq_puts(s, " disabled\n");
440 continue;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: get_random_bytes returns bad randomness before seeding is complete
On Sat, Jun 3, 2017 at 5:45 PM, Sandy Harris wrote: > ... > Of course this will fail on systems with no high-res timer. Are there > still some of those? It might be done in about 1000 times as long on a > system that lacks the realtime library's nanosecond timer but has the > Posix standard microsecond timer, implying a delay time in the > milliseconds. Would that be acceptable in those cases? A significant portion of the use cases should include mobile devices. Device sales outnumbered desktop and server sales several years ago. Many devices are sensor rich. Even the low-end ones come with accelorometers for gaming. A typical one has 3 or 4 sensors, and higher-end ones have 7 or 8 sensors. An Evo 4G has 7 of them. There's no wanting for entropy in many of the use cases. The thing that is lacking seems to be taking advantage of it. Jeff
[PATCH] staging: rtl8723bs: fix another spelling mistake
From: Colin Ian King
I found one more spelling mistake in a DBG_8192C debug message,
replace "avaliable" with "available", add some spacing between
text and a number and split overly long line
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
index 163537faefd9..84a89ef74169 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
@@ -1741,7 +1741,8 @@ static u8 hal_EfusePgPacketWrite2ByteHeader(
efuse_addr = *pAddr;
if (efuse_addr >= efuse_max_available_len) {
- DBG_8192C("%s: addr(%d) over avaliable(%d)!!\n", __func__,
efuse_addr, efuse_max_available_len);
+ DBG_8192C("%s: addr(%d) over available (%d)!!\n", __func__,
+ efuse_addr, efuse_max_available_len);
return false;
}
--
2.11.0
[PATCH v2] lib/extable.c: use bsearch() library function in search_extable()
Signed-off-by: Thomas Meyer
---
include/linux/extable.h | 3 ++-
kernel/extable.c| 2 +-
kernel/module.c | 2 +-
lib/extable.c | 38 +++---
4 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/include/linux/extable.h b/include/linux/extable.h
index 7effea4..b575bb9 100644
--- a/include/linux/extable.h
+++ b/include/linux/extable.h
@@ -2,13 +2,14 @@
#define _LINUX_EXTABLE_H
#include /* for NULL */
+#include
struct module;
struct exception_table_entry;
const struct exception_table_entry *
search_extable(const struct exception_table_entry *first,
- const struct exception_table_entry *last,
+ const size_t num,
unsigned long value);
void sort_extable(struct exception_table_entry *start,
struct exception_table_entry *finish);
diff --git a/kernel/extable.c b/kernel/extable.c
index 2676d7f..0c25b75 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -55,7 +55,7 @@ const struct exception_table_entry
*search_exception_tables(unsigned long addr)
{
const struct exception_table_entry *e;
- e = search_extable(__start___ex_table, __stop___ex_table-1, addr);
+ e = search_extable(__start___ex_table, __stop___ex_table -
__start___ex_table, addr);
if (!e)
e = search_module_extables(addr);
return e;
diff --git a/kernel/module.c b/kernel/module.c
index 4a3665f..22faf11 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4201,7 +4201,7 @@ const struct exception_table_entry
*search_module_extables(unsigned long addr)
goto out;
e = search_extable(mod->extable,
- mod->extable + mod->num_exentries - 1,
+ mod->num_exentries,
addr);
out:
preempt_enable();
diff --git a/lib/extable.c b/lib/extable.c
index 62968da..d4d3929 100644
--- a/lib/extable.c
+++ b/lib/extable.c
@@ -9,6 +9,7 @@
* 2 of the License, or (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -51,7 +52,7 @@ static void swap_ex(void *a, void *b, int size)
* This is used both for the kernel exception table and for
* the exception tables of modules that get loaded.
*/
-static int cmp_ex(const void *a, const void *b)
+static int cmp_ex_sort(const void *a, const void *b)
{
const struct exception_table_entry *x = a, *y = b;
@@ -67,7 +68,7 @@ void sort_extable(struct exception_table_entry *start,
struct exception_table_entry *finish)
{
sort(start, finish - start, sizeof(struct exception_table_entry),
- cmp_ex, swap_ex);
+ cmp_ex_sort, swap_ex);
}
#ifdef CONFIG_MODULES
@@ -93,6 +94,20 @@ void trim_init_extable(struct module *m)
#endif /* !ARCH_HAS_SORT_EXTABLE */
#ifndef ARCH_HAS_SEARCH_EXTABLE
+
+static int cmp_ex_search(const void *key, const void *elt)
+{
+ const struct exception_table_entry * _elt = elt;
+ unsigned long k = *(unsigned long*) key;
+
+ /* avoid overflow */
+ if (k > ex_to_insn(_elt))
+ return 1;
+ if (k < ex_to_insn(_elt))
+ return -1;
+ return 0;
+}
+
/*
* Search one exception table for an entry corresponding to the
* given instruction address, and return the address of the entry,
@@ -102,24 +117,9 @@ void trim_init_extable(struct module *m)
*/
const struct exception_table_entry *
search_extable(const struct exception_table_entry *first,
- const struct exception_table_entry *last,
+ const size_t num,
unsigned long value)
{
- while (first <= last) {
- const struct exception_table_entry *mid;
-
- mid = ((last - first) >> 1) + first;
- /*
- * careful, the distance between value and insn
- * can be larger than MAX_LONG:
- */
- if (ex_to_insn(mid) < value)
- first = mid + 1;
- else if (ex_to_insn(mid) > value)
- last = mid - 1;
- else
- return mid;
- }
- return NULL;
+ return bsearch(&value, first, num, sizeof(struct
exception_table_entry), cmp_ex_search);
}
#endif
Re: [kernel-hardening] [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
On 06/03/2017 06:39 AM, Jann Horn wrote: On Sat, Jun 3, 2017 at 7:53 AM, Matt Brown wrote: This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature in Grsecurity and also incorporates logging ideas from cormander's tpe-lkm. Modifications from the Grsecurity implementation of TPE were made to turn it into a stackable LSM using the existing LSM hook bprm_set_creds. Also, denial messages were improved by including the full path of the disallowed program. (This idea was taken from cormander's tpe-lkm) [...] Threat Models: [...] 2. Attacker on system replaces binary used by a privileged user with a malicious one * This situation arises when administrator of a system leaves a binary as world writable. * TPE is very effective against this threat model How do you end up with world-writable binaries in $PATH? Sys Admin screw up. It also protects against world-writable binaries anywhere on the system, not just in $PATH.
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
On 06/03/2017 06:00 PM, Alan Cox wrote: TIOCSLCKTRMIOS That one I'm more dubious about TIOCSLTC TIOCSSOFTCAR tty_io.c also has a few and n_tty has a couple we'd want. would it be overkill to have a sysctl kernel.ttyioctlwhitelist.X where X is one of the ioctls above? Why would anyone want to change the entries on that list Did you see Serge's proposed solution? I want us to not be talking past each other. Serge proposed the following: | By default, nothing changes - you can use those on your own tty, need | CAP_SYS_ADMIN against init_user_ns otherwise. | | Introduce a new CAP_TTY_PRIVILEGED. | | When may_push_chars is removed from the whitelist, you lose the | ability to use TIOCSTI on a tty - even your own - if you do not have | CAP_TTY_PRIVILEGED against the tty's user_ns. The question is how do you add/remove something from this whitelist? I assume by add/remove we don't mean that you have to recompile your kernel to change the whitelist! you earlier said you wanted the check to look like this: | if (!whitelisted(ioctl) && different_namespace && magic_flag) I want to know which namespace you are talking about here. Did you mean user_namespace? (the namespace I added tracking for in the tty_struct)
[PATCH] staging: rtl8723bs: fix a couple of spelling mistakes
From: Colin Ian King
Replace cant with cannot, argumetns with arguments and
add line break to overly long DBG_871X statement.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8723bs/hal/hal_com.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_com.c
b/drivers/staging/rtl8723bs/hal/hal_com.c
index 1880d4140bee..c5b715753725 100644
--- a/drivers/staging/rtl8723bs/hal/hal_com.c
+++ b/drivers/staging/rtl8723bs/hal/hal_com.c
@@ -26,7 +26,7 @@ u8 rtw_hal_data_init(struct adapter *padapter)
padapter->hal_data_sz = sizeof(struct hal_com_data);
padapter->HalData = vzalloc(padapter->hal_data_sz);
if (padapter->HalData == NULL) {
- DBG_8192C("cant not alloc memory for HAL DATA\n");
+ DBG_8192C("cannot not alloc memory for HAL DATA\n");
return _FAIL;
}
}
@@ -1415,7 +1415,8 @@ bool GetHexValueFromString(char *szStr, u32 *pu4bVal, u32
*pu4bMove)
/* Check input parameter. */
if (szStr == NULL || pu4bVal == NULL || pu4bMove == NULL) {
- DBG_871X("GetHexValueFromString(): Invalid inpur argumetns!
szStr: %p, pu4bVal: %p, pu4bMove: %p\n", szStr, pu4bVal, pu4bMove);
+ DBG_871X("GetHexValueFromString(): Invalid input arguments!
szStr: %p, pu4bVal: %p, pu4bMove: %p\n",
+szStr, pu4bVal, pu4bMove);
return false;
}
--
2.11.0
Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes
On Sat, Jun 3, 2017 at 11:29 PM, Peter Rosin wrote:
> On 2017-06-03 22:26, Luc Van Oostenryck wrote:
>> On Sat, Jun 3, 2017 at 9:34 PM, Greg Kroah-Hartman
>> wrote:
>>> On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote:
On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman
wrote:
> On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
>> From: Peter Rosin
>>
>> Hi Greg,
>>
>> Philipp found problems in v14 with using a mutex for locking that was
>> the outcome of the review for v13, so I'm now using a semaphore instead
>> of the rwsem that was in v13. That at least got rid of the scary call
>> to downgrade_write. However, I'm still unsure about what you actually
>> meant with your comment about lack of sparse markings [1]. I did add
>> __must_check to the funcs that selects the mux, but I've got this
>> feeling that this is not what you meant?
>
> I thought there was a way to mark a function as requiring a lock be held
> when it is being called. Does sparse not support that anymore?
sparse still support these annotations, of course.
In this case, I suppose you're talking about '__must_hold()' which
*must* be used instead of a pair of '__releases()' + '__acquires()'
when the lock is help on function entry and exit.
>>>
>>> Ah, yes, that's what I was thinking of. I don't know if sparse can
>>> track things like this across an exported symbol, so I doubt it really
>>> will help here. Sorry for the noise.
>>
>> No problem, I'm glad to help for sparse related things.
>>
>> I didn't saw the code in question because the lkml.org link Peter
>> gave didn't work for me and I don't know much about exported symbols
>> (but I think the sole effect is to add some data in some symbol table).
>> But these annotations just work based on the declarations, very much
>> like type checking. So if you have something in scope like the following:
>>
>> void do_stuff_locked(struct s *ptr) __must_hold(*ptr);
>>
>> ...
>>
>> void do_stuff_unlocked(struct s *ptr)
>> {
>> ...
>> do_stuff_locked(ptr);// will warn
>> ...
>> }
>>
>> You will have a warning from sparse unless the code preceding and following
>> the call to do_stuff_locked() lock & then unlock 'ptr', generaly
>> indirectly by a pair
>> of functions, the one before with an '__acquires()' in its declaration
>> the one after
>> with a '__releases()' in its declaration:
>>
>> void lock_stuff(struct s *ptr) __acquires(*ptr);
>> void unlock_stuff(struct s *ptr) __releases(*ptr);
>>
>> void do_stuff_unlocked(struct s *ptr)
>> {
>> lock_stuff(ptr);
>> do_stuff_locked(ptr);// won't warn
>> unlock_stuff(ptr);
>> }
>
> Ok, thanks for the explanation! The above was what I gathered when I
> looked around, and since it didn't really fit the usage pattern of the
> mux api I was stomped. When comparing the mux code with the above,
> mux_control_select would be an __acquires (albeit a conditional one,
> but let's not muddy the waters unnecessarily) and mux_control_deselect
> would be a __releases.
>
> But for long time mux consumers, like the video mux, it must be OK to
> only acquire the mux, and not release it right away in the same context,
> which I assume will be very hard for sparse to handle sanely? E.g. I
> think sparse also complains if there are unbalanced __acquires and
> __releases in some context, no?
Yes, there are some limitations.
You can do conditional locks, it's what spin_trylock() and
{read,write}_trylock()
do. something like the following will be OK:
void do_stuff_unlocked(struct s *ptr)
{
if (trylock_stuff(ptr)) {
do_stuff_locked(ptr);// won't warn
unlock_stuff(ptr);
}
}
sparse won't complain because everything is correct within each block.
But something that sparse will complain about would be:
void foobar(struct s *ptr)
{
if (some condition)
lock_stuff(ptr);
// will warn
... some code ...
if (same condition) {
do_stuff_locked(ptr);
unlock_stuff(ptr);
}
}
While correct from the point of view of locking, sparse won't be able
to take into account
that indeed, the two ifs are fro the same condition. sparse will only
see that after the first
if there will be one path where the lock will be held and another one
where it won't and
will this issue a 'different lock contexts for basic block' warning.
For this mux code, for example, the function mux_control_select() will
have a problem
because depending on the return value of __mux_control_select() you will want to
take back the lock or not, so the exit state of this function is not
well defined regarding
locking. It's the same for mux_control_try_select().
I hope this render the possibilities a bit clearer.
Cheers,
-- Luc
Re: [PATCH v2] misc: atmel-ssc: Handle return value of clk_prepare_enable and clk_prepare
Hi,
It is getting tiring to get patches that are nor even compile tested
resulting from whatever static analysis tool you used.
This patch has almost no value and v1 was clearly wrong.
Do you realize clk_prepare and clk_prepare_enable will never fail for
the SSC?
On 02/06/2017 at 11:09:02 +0530, Arvind Yadav wrote:
> clk_prepare_enable() and clk_prepare() can fail here and
> we must check its return value.
>
> Signed-off-by: Arvind Yadav
> ---
> drivers/misc/atmel-ssc.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index b2a0340..df34b81 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -30,6 +30,7 @@ struct ssc_device *ssc_request(unsigned int ssc_num)
> {
> int ssc_valid = 0;
> struct ssc_device *ssc;
> + int ret;
>
> spin_lock(&user_lock);
> list_for_each_entry(ssc, &ssc_list, list) {
> @@ -60,7 +61,11 @@ struct ssc_device *ssc_request(unsigned int ssc_num)
> ssc->user++;
> spin_unlock(&user_lock);
>
> - clk_prepare(ssc->clk);
> + ret = clk_prepare(ssc->clk);
> + if (ret) {
> + pr_err("Failed to prepare clock\n");
> + return ERR_PTR(ret);
> + }
>
> return ssc;
> }
> @@ -195,6 +200,7 @@ static int ssc_probe(struct platform_device *pdev)
> struct resource *regs;
> struct ssc_device *ssc;
> const struct atmel_ssc_platform_data *plat_dat;
> + int ret;
>
> ssc = devm_kzalloc(&pdev->dev, sizeof(struct ssc_device), GFP_KERNEL);
> if (!ssc) {
> @@ -229,7 +235,9 @@ static int ssc_probe(struct platform_device *pdev)
> }
>
> /* disable all interrupts */
> - clk_prepare_enable(ssc->clk);
> + ret = clk_prepare_enable(ssc->clk);
> + if (ret)
> + return ret;
> ssc_writel(ssc->regs, IDR, -1);
> ssc_readl(ssc->regs, SR);
> clk_disable_unprepare(ssc->clk);
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver
Hi! > > > According to the docs V4L2_CID_EXPOSURE_ABSOLUTE is in 100 usec units. > > > > > > OTOH V4L2_CID_EXPOSURE has no defined unit, so it's a better fit IMO. > > > >Way more drivers appear to be using EXPOSURE than EXPOSURE_ABSOLUTE, too. > > > > > > Done, switched to V4L2_CID_EXPOSURE. It's true, this control is not > > > taking 100 usec units, so unit-less is better. > > > > Thanks. If you know the units, it would be of course better to use > > right units... > > Steve: what's the unit in this case? Is it lines or something else? > > Pavel: we do need to make sure the user space will be able to know the unit, > too. It's rather a case with a number of controls: the unit is known but > there's no API to convey it to the user. > > The exposure is a bit special, too: granularity matters a lot on small > values. On most other controls it does not. Yeah. Basically problem with exposure is that the control is logarithmic; by using linear scale we got too much resolution at long times and too little resolution at short times. (Plus, 100 usec ... n900 can do times _way_ shorter than that.) Anyway, even u32 gives us enough range, but I so the linear/log confusion does not matter. But it would be nicer if values were in 10 usec or usec, not 100 usec... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH 0/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support
From: Nicholas Bellinger Hi Himanshu + Quinn, Here is a small series to introduce proper percpu se_lun->lun_ref counting for TMR, and add common code in target_submit_tmr() to do tag lookup for unpacked_lun in order to drop the original driver specific lookup within __qlt_24xx_handle_abts(). It's rather straight-forward, so review and test as a v4.13 item. Thanks! Nicholas Bellinger (3): target: Add support for TMR percpu reference counting target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK qla2xxx: Convert QLA_TGT_ABTS to TARGET_SCF_LOOKUP_LUN_FROM_TAG drivers/scsi/qla2xxx/qla_target.c | 39 ++- drivers/scsi/qla2xxx/tcm_qla2xxx.c | 4 ++- drivers/target/target_core_device.c| 14 ++--- drivers/target/target_core_transport.c | 56 -- include/target/target_core_base.h | 3 +- 5 files changed, 71 insertions(+), 45 deletions(-) -- 1.9.1
[PATCH 1/3] target: Add support for TMR percpu reference counting
From: Nicholas Bellinger
This patch introduces TMR percpu reference counting using
se_lun->lun_ref in transport_lookup_tmr_lun(), following
how existing non TMR per se_lun reference counting works
within transport_lookup_cmd_lun().
It also adds explicit transport_lun_remove_cmd() calls to
drop the reference in the three tmr related locations that
invoke transport_cmd_check_stop_to_fabric();
- target_tmr_work() during normal ->queue_tm_rsp()
- target_complete_tmr_failure() during error ->queue_tm_rsp()
- transport_generic_handle_tmr() during early failure
Also, note the exception paths in transport_generic_free_cmd()
and transport_cmd_finish_abort() already check SCF_SE_LUN_CMD,
and will invoke transport_lun_remove_cmd() when necessary.
Cc: Himanshu Madhani
Cc: Quinn Tran
Cc: Mike Christie
Cc: Hannes Reinecke
Cc: Christoph Hellwig
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_device.c| 14 ++
drivers/target/target_core_transport.c | 3 +++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/target/target_core_device.c
b/drivers/target/target_core_device.c
index 8f0e0e3..11c80c4 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -168,11 +168,20 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64
unpacked_lun)
rcu_read_lock();
deve = target_nacl_find_deve(nacl, unpacked_lun);
if (deve) {
- se_cmd->se_lun = rcu_dereference(deve->se_lun);
se_lun = rcu_dereference(deve->se_lun);
+
+ if (!percpu_ref_tryget_live(&se_lun->lun_ref)) {
+ se_lun = NULL;
+ goto out_unlock;
+ }
+
+ se_cmd->se_lun = rcu_dereference(deve->se_lun);
se_cmd->pr_res_key = deve->pr_res_key;
se_cmd->orig_fe_lun = unpacked_lun;
+ se_cmd->se_cmd_flags |= SCF_SE_LUN_CMD;
+ se_cmd->lun_ref_active = true;
}
+out_unlock:
rcu_read_unlock();
if (!se_lun) {
@@ -182,9 +191,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64
unpacked_lun)
unpacked_lun);
return -ENODEV;
}
- /*
-* XXX: Add percpu se_lun->lun_ref reference count for TMR
-*/
se_cmd->se_dev = rcu_dereference_raw(se_lun->lun_se_dev);
se_tmr->tmr_dev = rcu_dereference_raw(se_lun->lun_se_dev);
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index f16a789..83bfc97 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -1588,6 +1588,7 @@ static void target_complete_tmr_failure(struct
work_struct *work)
se_cmd->se_tmr_req->response = TMR_LUN_DOES_NOT_EXIST;
se_cmd->se_tfo->queue_tm_rsp(se_cmd);
+ transport_lun_remove_cmd(se_cmd);
transport_cmd_check_stop_to_fabric(se_cmd);
}
@@ -3199,6 +3200,7 @@ static void target_tmr_work(struct work_struct *work)
cmd->se_tfo->queue_tm_rsp(cmd);
check_stop:
+ transport_lun_remove_cmd(cmd);
transport_cmd_check_stop_to_fabric(cmd);
}
@@ -3221,6 +3223,7 @@ int transport_generic_handle_tmr(
pr_warn_ratelimited("handle_tmr caught CMD_T_ABORTED TMR %d"
"ref_tag: %llu tag: %llu\n", cmd->se_tmr_req->function,
cmd->se_tmr_req->ref_task_tag, cmd->tag);
+ transport_lun_remove_cmd(cmd);
transport_cmd_check_stop_to_fabric(cmd);
return 0;
}
--
1.9.1
[PATCH 3/3] qla2xxx: Convert QLA_TGT_ABTS to TARGET_SCF_LOOKUP_LUN_FROM_TAG
From: Nicholas Bellinger
Following Himanshu's earlier patch to drop the redundant tag
lookup within __qlt_24xx_handle_abts(), go ahead and drop this
now QLA_TGT_ABTS can use TARGET_SCF_LOOKUP_LUN_FROM_TAG and
have target_submit_tmr() do this from common code.
Cc: Himanshu Madhani
Cc: Quinn Tran
Cc: Mike Christie
Cc: Hannes Reinecke
Cc: Christoph Hellwig
Signed-off-by: Nicholas Bellinger
---
drivers/scsi/qla2xxx/qla_target.c | 39 +-
drivers/scsi/qla2xxx/tcm_qla2xxx.c | 4 +++-
2 files changed, 12 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_target.c
b/drivers/scsi/qla2xxx/qla_target.c
index 0e03ca2..401e245 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -1847,38 +1847,13 @@ static int __qlt_24xx_handle_abts(struct scsi_qla_host
*vha,
struct abts_recv_from_24xx *abts, struct fc_port *sess)
{
struct qla_hw_data *ha = vha->hw;
- struct se_session *se_sess = sess->se_sess;
struct qla_tgt_mgmt_cmd *mcmd;
- struct se_cmd *se_cmd;
- u32 lun = 0;
int rc;
- bool found_lun = false;
- unsigned long flags;
-
- spin_lock_irqsave(&se_sess->sess_cmd_lock, flags);
- list_for_each_entry(se_cmd, &se_sess->sess_cmd_list, se_cmd_list) {
- struct qla_tgt_cmd *cmd =
- container_of(se_cmd, struct qla_tgt_cmd, se_cmd);
- if (se_cmd->tag == abts->exchange_addr_to_abort) {
- lun = cmd->unpacked_lun;
- found_lun = true;
- break;
- }
- }
- spin_unlock_irqrestore(&se_sess->sess_cmd_lock, flags);
- /* cmd not in LIO lists, look in qla list */
- if (!found_lun) {
- if (abort_cmd_for_tag(vha, abts->exchange_addr_to_abort)) {
- /* send TASK_ABORT response immediately */
- qlt_24xx_send_abts_resp(vha, abts, FCP_TMF_CMPL, false);
- return 0;
- } else {
- ql_dbg(ql_dbg_tgt_mgt, vha, 0xf081,
- "unable to find cmd in driver or LIO for tag
0x%x\n",
- abts->exchange_addr_to_abort);
- return -ENOENT;
- }
+ if (abort_cmd_for_tag(vha, abts->exchange_addr_to_abort)) {
+ /* send TASK_ABORT response immediately */
+ qlt_24xx_send_abts_resp(vha, abts, FCP_TMF_CMPL, false);
+ return 0;
}
ql_dbg(ql_dbg_tgt_mgt, vha, 0xf00f,
@@ -1899,7 +1874,11 @@ static int __qlt_24xx_handle_abts(struct scsi_qla_host
*vha,
mcmd->reset_count = vha->hw->chip_reset;
mcmd->tmr_func = QLA_TGT_ABTS;
- rc = ha->tgt.tgt_ops->handle_tmr(mcmd, lun, mcmd->tmr_func,
+ /*
+* LUN is looked up by target-core internally based on the passed
+* abts->exchange_addr_to_abort tag.
+*/
+ rc = ha->tgt.tgt_ops->handle_tmr(mcmd, 0, mcmd->tmr_func,
abts->exchange_addr_to_abort);
if (rc != 0) {
ql_dbg(ql_dbg_tgt_mgt, vha, 0xf052,
diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
index 7443e4e..75aeb9f 100644
--- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
+++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
@@ -601,11 +601,13 @@ static int tcm_qla2xxx_handle_tmr(struct qla_tgt_mgmt_cmd
*mcmd, uint32_t lun,
struct fc_port *sess = mcmd->sess;
struct se_cmd *se_cmd = &mcmd->se_cmd;
int transl_tmr_func = 0;
+ int flags = TARGET_SCF_ACK_KREF;
switch (tmr_func) {
case QLA_TGT_ABTS:
pr_debug("%ld: ABTS received\n", sess->vha->host_no);
transl_tmr_func = TMR_ABORT_TASK;
+ flags |= TARGET_SCF_LOOKUP_LUN_FROM_TAG;
break;
case QLA_TGT_2G_ABORT_TASK:
pr_debug("%ld: 2G Abort Task received\n", sess->vha->host_no);
@@ -638,7 +640,7 @@ static int tcm_qla2xxx_handle_tmr(struct qla_tgt_mgmt_cmd
*mcmd, uint32_t lun,
}
return target_submit_tmr(se_cmd, sess->se_sess, NULL, lun, mcmd,
- transl_tmr_func, GFP_ATOMIC, tag, TARGET_SCF_ACK_KREF);
+ transl_tmr_func, GFP_ATOMIC, tag, flags);
}
static int tcm_qla2xxx_queue_data_in(struct se_cmd *se_cmd)
--
1.9.1
[PATCH 2/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK
From: Nicholas Bellinger
This patch introduces support in target_submit_tmr() for locating a
unpacked_lun from an existing se_cmd->tag during ABORT_TASK.
When TARGET_SCF_LOOKUP_LUN_FROM_TAG is set, target_submit_tmr()
will do the extra lookup via target_lookup_lun_from_tag() and
subsequently invoke transport_lookup_tmr_lun() so a proper
percpu se_lun->lun_ref is taken before workqueue dispatch into
se_device->tmr_wq happens.
Aside from the extra target_lookup_lun_from_tag(), the existing
code-path remains unchanged.
Cc: Himanshu Madhani
Cc: Quinn Tran
Cc: Mike Christie
Cc: Hannes Reinecke
Cc: Christoph Hellwig
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_transport.c | 53 --
include/target/target_core_base.h | 3 +-
2 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 83bfc97..dbb8101 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -1592,6 +1592,29 @@ static void target_complete_tmr_failure(struct
work_struct *work)
transport_cmd_check_stop_to_fabric(se_cmd);
}
+static bool target_lookup_lun_from_tag(struct se_session *se_sess, u64 tag,
+ u64 *unpacked_lun)
+{
+ struct se_cmd *se_cmd;
+ unsigned long flags;
+ bool ret = false;
+
+ spin_lock_irqsave(&se_sess->sess_cmd_lock, flags);
+ list_for_each_entry(se_cmd, &se_sess->sess_cmd_list, se_cmd_list) {
+ if (se_cmd->se_cmd_flags & SCF_SCSI_TMR_CDB)
+ continue;
+
+ if (se_cmd->tag == tag) {
+ *unpacked_lun = se_cmd->orig_fe_lun;
+ ret = true;
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&se_sess->sess_cmd_lock, flags);
+
+ return ret;
+}
+
/**
* target_submit_tmr - lookup unpacked lun and submit uninitialized se_cmd
* for TMR CDBs
@@ -1639,19 +1662,31 @@ int target_submit_tmr(struct se_cmd *se_cmd, struct
se_session *se_sess,
core_tmr_release_req(se_cmd->se_tmr_req);
return ret;
}
+ /*
+* If this is ABORT_TASK with no explicit fabric provided LUN,
+* go ahead and search active session tags for a match to figure
+* out unpacked_lun for the original se_cmd.
+*/
+ if (tm_type == TMR_ABORT_TASK && (flags &
TARGET_SCF_LOOKUP_LUN_FROM_TAG)) {
+ if (!target_lookup_lun_from_tag(se_sess, tag, &unpacked_lun))
+ goto failure;
+ }
ret = transport_lookup_tmr_lun(se_cmd, unpacked_lun);
- if (ret) {
- /*
-* For callback during failure handling, push this work off
-* to process context with TMR_LUN_DOES_NOT_EXIST status.
-*/
- INIT_WORK(&se_cmd->work, target_complete_tmr_failure);
- schedule_work(&se_cmd->work);
- return 0;
- }
+ if (ret)
+ goto failure;
+
transport_generic_handle_tmr(se_cmd);
return 0;
+
+ /*
+* For callback during failure handling, push this work off
+* to process context with TMR_LUN_DOES_NOT_EXIST status.
+*/
+failure:
+ INIT_WORK(&se_cmd->work, target_complete_tmr_failure);
+ schedule_work(&se_cmd->work);
+ return 0;
}
EXPORT_SYMBOL(target_submit_tmr);
diff --git a/include/target/target_core_base.h
b/include/target/target_core_base.h
index db2c7b3..a3af69f 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -188,7 +188,8 @@ enum target_sc_flags_table {
TARGET_SCF_BIDI_OP = 0x01,
TARGET_SCF_ACK_KREF = 0x02,
TARGET_SCF_UNKNOWN_SIZE = 0x04,
- TARGET_SCF_USE_CPUID= 0x08,
+ TARGET_SCF_USE_CPUID= 0x08,
+ TARGET_SCF_LOOKUP_LUN_FROM_TAG = 0x10,
};
/* fabric independent task management function values */
--
1.9.1
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
> TIOCSLCKTRMIOS That one I'm more dubious about > TIOCSLTC > TIOCSSOFTCAR tty_io.c also has a few and n_tty has a couple we'd want. > > would it be overkill to have a sysctl kernel.ttyioctlwhitelist.X where X > is one of the ioctls above? Why would anyone want to change the entries on that list Alan
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver
On Sat, Jun 03, 2017 at 09:51:39PM +0200, Pavel Machek wrote: > Hi! > > > >>>+/* Auto/manual exposure */ > > >>>+ctrls->auto_exp = v4l2_ctrl_new_std_menu(hdl, ops, > > >>>+ V4L2_CID_EXPOSURE_AUTO, > > >>>+ V4L2_EXPOSURE_MANUAL, > > >>>0, > > >>>+ V4L2_EXPOSURE_AUTO); > > >>>+ctrls->exposure = v4l2_ctrl_new_std(hdl, ops, > > >>>+V4L2_CID_EXPOSURE_ABSOLUTE, > > >>>+0, 65535, 1, 0); > > >> > > >>Is exposure_absolute supposed to be in microseconds...? > > > > > >Yes. > > > > According to the docs V4L2_CID_EXPOSURE_ABSOLUTE is in 100 usec units. > > > > OTOH V4L2_CID_EXPOSURE has no defined unit, so it's a better fit IMO. > > >Way more drivers appear to be using EXPOSURE than EXPOSURE_ABSOLUTE, too. > > > > Done, switched to V4L2_CID_EXPOSURE. It's true, this control is not > > taking 100 usec units, so unit-less is better. > > Thanks. If you know the units, it would be of course better to use > right units... Steve: what's the unit in this case? Is it lines or something else? Pavel: we do need to make sure the user space will be able to know the unit, too. It's rather a case with a number of controls: the unit is known but there's no API to convey it to the user. The exposure is a bit special, too: granularity matters a lot on small values. On most other controls it does not. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
[git pull] Input updates for v4.12-rc3
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get a couple regression fixes in synaptics and axp20x-pek drivers, and we will try to ease transition from PS/2 to RMI for Synaptics touchpad users by ensuring we do not try to activate RMI mode when RMI SMBus support is not enabled, and nag users a bit to enable it. Plus a couple of other changes that seemed worthwhile for this release. Changelog: - Andi Shyti (1): Input: tm2-touchkey - use LEN_ON as boolean value instead of LED_FULL Benjamin Tissoires (3): Input: synaptics - keep PS/2 around when RMI4_SMB is not enabled Input: synaptics - warn the users when there is a better mode Input: synaptics - tell users to report when they should be using rmi-smbus Eric Biggers (1): Input: synaptics - clear device info before filling in Hans de Goede (3): Input: silead - disable interrupt during suspend Input: axp20x-pek - only check for "INTCFD9" ACPI device on Cherry Trail Input: axp20x-pek - switch to acpi_dev_present and check for ACPI0011 too Diffstat: drivers/input/keyboard/tm2-touchkey.c | 2 +- drivers/input/misc/axp20x-pek.c | 44 +-- drivers/input/mouse/synaptics.c | 37 ++--- drivers/input/touchscreen/silead.c| 3 +++ 4 files changed, 69 insertions(+), 17 deletions(-) Thanks. -- Dmitry
Re: [PATCH] parport_serial: Add support for WCH CH382L PCI-E Single Parallel Port Card Adapter.
On Thursday 27 April 2017 05:07 PM, Alexander Gerasiov wrote:
PCIID: 0x1c00:0x3050.
Similair to 0x3250 but without serial ports soldered on board.
Signed-off-by: Alexander Gerasiov
---
Can you please send a v2 of this patch with little more details in the
commit message..
For example, look at this commit - 2fdd8c8c5304 ("parport: Add support
for the WCH382 2S/1P multi-IO card")
--
Regards
Sudip
Re: get_random_bytes returns bad randomness before seeding is complete
Stephan's driver, the HAVEGE system & several others purport to extract entropy from a series of timer calls. Probably the best analysis is in the Mcguire et al. paper at https://static.lwn.net/images/conf/rtlws11/random-hardware.pdf & the simplest code in my user-space driver at https://github.com/sandy-harris/maxwell The only kernel-space code I know of is Stephan's. If the claim that such calls give entropy is accepted (which I think it should be) then if we get one bit per call, need 100 or so bits & space the calls 100 ns apart, loading up a decent chunk of startup entropy takes about 10,000 ns or 10 microseconds which looks like an acceptable delay. Can we just do that very early in the boot process? Of course this will fail on systems with no high-res timer. Are there still some of those? It might be done in about 1000 times as long on a system that lacks the realtime library's nanosecond timer but has the Posix standard microsecond timer, implying a delay time in the milliseconds. Would that be acceptable in those cases?
Re: [PATCH v3 3/9] mfd: tmio.h: support partition parser types
On Thu, Jun 1, 2017 at 4:35 PM, Lee Jones wrote:
> On Thu, 01 Jun 2017, Andrea Adami wrote:
>
>> Signed-off-by: Andrea Adami
>> ---
>> include/linux/mfd/tmio.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
>> index a1520d8..23bb069 100644
>> --- a/include/linux/mfd/tmio.h
>> +++ b/include/linux/mfd/tmio.h
>> @@ -139,6 +139,7 @@ struct tmio_nand_data {
>> struct nand_bbt_descr *badblock_pattern;
>> struct mtd_partition*partition;
>> unsigned intnum_partitions;
>> + const char *const *types; /* names of parsers to use if any */
>
> Please use kerneldoc instead.
>
Thanks for the review.
tmio.h is not consistent and uses inline comments so I did not change the style.
Another round of patches will be necessary to sanitize the comments,
out of the scope of this little patchset.
Cheers
Andrea
>> };
>>
>> #define FBIO_TMIO_ACC_WRITE 0x7C639300
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes
On 2017-06-03 12:31, Greg Kroah-Hartman wrote: > On Sat, Jun 03, 2017 at 07:26:27PM +0900, Greg Kroah-Hartman wrote: >> On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote: >>> From: Peter Rosin >>> >>> Hi Greg, >>> >>> Philipp found problems in v14 with using a mutex for locking that was >>> the outcome of the review for v13, so I'm now using a semaphore instead >>> of the rwsem that was in v13. That at least got rid of the scary call >>> to downgrade_write. However, I'm still unsure about what you actually >>> meant with your comment about lack of sparse markings [1]. I did add >>> __must_check to the funcs that selects the mux, but I've got this >>> feeling that this is not what you meant? >> >> I thought there was a way to mark a function as requiring a lock be held >> when it is being called. Does sparse not support that anymore? > > Anyway, not a big deal. I still worry about the calls blocking when > people are not expecting them to, but it is just the nature of th api I > guess. Yeah, first come first serve. I don't know what else I can do, except maybe follow up with a timed version of mux_control_select()... > All now queued up, nice work, thanks for sticking with this. *big sigh of relief* I was getting pretty fed up with the series to be honest :-), so thanks a bunch for taking it! Cheers, peda
Re: [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Thomas,
Am 03.06.2017 um 23:25 schrieb Thomas Meyer:
> ptrace(PTRACE_CONT, 21664, NULL, SIG_0) = 0
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_TRAPPED, si_pid=21664,
> si_uid=1000, si_status=SIGTRAP, si_utime=0, si_stime=0} ---
> wait4(21664, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], WSTOPPED|__WALL,
> NULL) = 21664
> ptrace(PTRACE_SETREGS, 21664, NULL, 0x60f7fa20) = 0
> ptrace(PTRACE_CONT, 21664, NULL, SIG_0) = 0
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_TRAPPED, si_pid=21664,
> si_uid=1000, si_status=SIGTRAP, si_utime=0, si_stime=0} ---
> wait4(21664, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], WSTOPPED|__WALL,
> NULL) = 21664
> ptrace(PTRACE_SETREGS, 21664, NULL, 0xb18bc4e0) = 0
> ptrace(PTRACE_SETREGSET, 21664, NT_X86_XSTATE, [{iov_base=0xb18bc5b8,
> iov_len=832}]) = -1 EFAULT (Bad address)
> ioctl(1, TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
>
> don't know why gdb shows errno as 4...
Interesting. This makes much more sense than -EINTR.
I've allocated an i7 machine at $dayjob and hope to be able to able reproduce
soon.
Let's gets resolved that mess and apply all the fixes. :-)
Thanks,
//richard
[GIT PULL] SCSI fixes for 4.12-rc3
This is nine fixes, seven of which are for the qedi driver (new in
4.10) the other two are a use after free in the cxgbi drivers and a
potential NULL dereference in the rdac device handler.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Artem Savkov (1):
scsi: scsi_dh_rdac: Use ctlr directly in rdac_failover_get()
Arun Easi (1):
scsi: qedi: Fix bad pte call trace when iscsiuio is stopped.
Nilesh Javali (1):
scsi: qedi: set max_fin_rt default value
Varun Prakash (1):
scsi: libcxgbi: fix skb use after free
manish.rangan...@cavium.com (5):
scsi: qedi: Fix endpoint NULL panic during recovery.
scsi: qedi: Set firmware tcp msl timer value.
scsi: qedi: Fix endpoint NULL panic in qedi_set_path.
scsi: qedi: Set dma_boundary to 0xfff.
scsi: qedi: Correctly set firmware max supported BDs.
and diffstat:
drivers/scsi/cxgbi/libcxgbi.c | 25 ++---
drivers/scsi/cxgbi/libcxgbi.h | 16
drivers/scsi/device_handler/scsi_dh_rdac.c | 10 --
drivers/scsi/qedi/qedi.h | 3 ++-
drivers/scsi/qedi/qedi_fw.c| 2 ++
drivers/scsi/qedi/qedi_iscsi.c | 7 ++-
drivers/scsi/qedi/qedi_main.c | 25 +
7 files changed, 53 insertions(+), 35 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index bd7d39ecbd24..fb06974c88c1 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -1873,6 +1873,11 @@ int cxgbi_conn_alloc_pdu(struct iscsi_task *task, u8
opcode)
tcp_task->dd_data = tdata;
task->hdr = NULL;
+ if (tdata->skb) {
+ kfree_skb(tdata->skb);
+ tdata->skb = NULL;
+ }
+
if (SKB_MAX_HEAD(cdev->skb_tx_rsvd) > (512 * MAX_SKB_FRAGS) &&
(opcode == ISCSI_OP_SCSI_DATA_OUT ||
(opcode == ISCSI_OP_SCSI_CMD &&
@@ -1890,6 +1895,7 @@ int cxgbi_conn_alloc_pdu(struct iscsi_task *task, u8
opcode)
return -ENOMEM;
}
+ skb_get(tdata->skb);
skb_reserve(tdata->skb, cdev->skb_tx_rsvd);
task->hdr = (struct iscsi_hdr *)tdata->skb->data;
task->hdr_max = SKB_TX_ISCSI_PDU_HEADER_MAX; /* BHS + AHS */
@@ -2035,9 +2041,9 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
unsigned int datalen;
int err;
- if (!skb) {
+ if (!skb || cxgbi_skcb_test_flag(skb, SKCBF_TX_DONE)) {
log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_PDU_TX,
- "task 0x%p, skb NULL.\n", task);
+ "task 0x%p, skb 0x%p\n", task, skb);
return 0;
}
@@ -2050,7 +2056,6 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
}
datalen = skb->data_len;
- tdata->skb = NULL;
/* write ppod first if using ofldq to write ppod */
if (ttinfo->flags & CXGBI_PPOD_INFO_FLAG_VALID) {
@@ -2078,6 +2083,7 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
pdulen += ISCSI_DIGEST_SIZE;
task->conn->txdata_octets += pdulen;
+ cxgbi_skcb_set_flag(skb, SKCBF_TX_DONE);
return 0;
}
@@ -2086,7 +2092,6 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
"task 0x%p, skb 0x%p, len %u/%u, %d EAGAIN.\n",
task, skb, skb->len, skb->data_len, err);
/* reset skb to send when we are called again */
- tdata->skb = skb;
return err;
}
@@ -2094,7 +2099,8 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
"itt 0x%x, skb 0x%p, len %u/%u, xmit err %d.\n",
task->itt, skb, skb->len, skb->data_len, err);
- kfree_skb(skb);
+ __kfree_skb(tdata->skb);
+ tdata->skb = NULL;
iscsi_conn_printk(KERN_ERR, task->conn, "xmit err %d.\n", err);
iscsi_conn_failure(task->conn, ISCSI_ERR_XMIT_FAILED);
@@ -2113,8 +2119,10 @@ void cxgbi_cleanup_task(struct iscsi_task *task)
tcp_task->dd_data = NULL;
/* never reached the xmit task callout */
- if (tdata->skb)
- __kfree_skb(tdata->skb);
+ if (tdata->skb) {
+ kfree_skb(tdata->skb);
+ tdata->skb = NULL;
+ }
task_release_itt(task, task->hdr_itt);
memset(tdata, 0, sizeof(*tdata));
@@ -2714,6 +2722,9 @@ EXPORT_SYMBOL_GPL(cxgbi_attr_is_visible);
static int __init libcxgbi_init_module(void)
{
pr_info("%s", version);
+
+ BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, cb) <
+sizeof(struct cxgbi_skb_cb));
return 0;
}
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 18e0ea83d361..239462a75760 100644
--- a/drivers/scsi/cxgbi/
Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes
On 2017-06-03 22:26, Luc Van Oostenryck wrote:
> On Sat, Jun 3, 2017 at 9:34 PM, Greg Kroah-Hartman
> wrote:
>> On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote:
>>> On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman
>>> wrote:
On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
> From: Peter Rosin
>
> Hi Greg,
>
> Philipp found problems in v14 with using a mutex for locking that was
> the outcome of the review for v13, so I'm now using a semaphore instead
> of the rwsem that was in v13. That at least got rid of the scary call
> to downgrade_write. However, I'm still unsure about what you actually
> meant with your comment about lack of sparse markings [1]. I did add
> __must_check to the funcs that selects the mux, but I've got this
> feeling that this is not what you meant?
I thought there was a way to mark a function as requiring a lock be held
when it is being called. Does sparse not support that anymore?
>>>
>>> sparse still support these annotations, of course.
>>> In this case, I suppose you're talking about '__must_hold()' which
>>> *must* be used instead of a pair of '__releases()' + '__acquires()'
>>> when the lock is help on function entry and exit.
>>
>> Ah, yes, that's what I was thinking of. I don't know if sparse can
>> track things like this across an exported symbol, so I doubt it really
>> will help here. Sorry for the noise.
>
> No problem, I'm glad to help for sparse related things.
>
> I didn't saw the code in question because the lkml.org link Peter
> gave didn't work for me and I don't know much about exported symbols
> (but I think the sole effect is to add some data in some symbol table).
> But these annotations just work based on the declarations, very much
> like type checking. So if you have something in scope like the following:
>
> void do_stuff_locked(struct s *ptr) __must_hold(*ptr);
>
> ...
>
> void do_stuff_unlocked(struct s *ptr)
> {
> ...
> do_stuff_locked(ptr);// will warn
> ...
> }
>
> You will have a warning from sparse unless the code preceding and following
> the call to do_stuff_locked() lock & then unlock 'ptr', generaly
> indirectly by a pair
> of functions, the one before with an '__acquires()' in its declaration
> the one after
> with a '__releases()' in its declaration:
>
> void lock_stuff(struct s *ptr) __acquires(*ptr);
> void unlock_stuff(struct s *ptr) __releases(*ptr);
>
> void do_stuff_unlocked(struct s *ptr)
> {
> lock_stuff(ptr);
> do_stuff_locked(ptr);// won't warn
> unlock_stuff(ptr);
> }
Ok, thanks for the explanation! The above was what I gathered when I
looked around, and since it didn't really fit the usage pattern of the
mux api I was stomped. When comparing the mux code with the above,
mux_control_select would be an __acquires (albeit a conditional one,
but let's not muddy the waters unnecessarily) and mux_control_deselect
would be a __releases.
But for long time mux consumers, like the video mux, it must be OK to
only acquire the mux, and not release it right away in the same context,
which I assume will be very hard for sparse to handle sanely? E.g. I
think sparse also complains if there are unbalanced __acquires and
__releases in some context, no?
Cheers,
peda
BTW, the core mux code is at the below link if the lkml link continues
to fail:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-testing&id=a3b02a9c6591ce154cd44e2383406390a45b530c
[PATCH] iscsi-target: Fix delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP
From: Nicholas Bellinger
This patch fixes a BUG() in iscsit_close_session() that could be
triggered when iscsit_logout_post_handler() execution from within
tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
(15 seconds), and the TCP connection didn't already close before
then forcing tx thread context to automatically exit.
This would manifest itself during explicit logout as:
[33206.974254] 1 connection(s) still exist for iSCSI session to
iqn.1993-08.org.debian:01:3f5523242179
[33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run:
2100.772 msecs
[33209.078643] [ cut here ]
[33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!
Normally when explicit logout attempt fails, the tx thread context
exits and iscsit_close_connection() from rx thread context does the
extra cleanup once it detects conn->conn_logout_remove has not been
cleared by the logout type specific post handlers.
To address this special case, if the logout post handler in tx thread
context detects conn->tx_thread_active has already been cleared, simply
return and exit in order for existing iscsit_close_connection()
logic from rx thread context do failed logout cleanup.
Reported-by: Bart Van Assche
Cc: Mike Christie
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: sta...@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index 0d8f815..c025451 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -4423,8 +4423,11 @@ static void iscsit_logout_post_handler_closesession(
* always sleep waiting for RX/TX thread shutdown to complete
* within iscsit_close_connection().
*/
- if (!conn->conn_transport->rdma_shutdown)
+ if (!conn->conn_transport->rdma_shutdown) {
sleep = cmpxchg(&conn->tx_thread_active, true, false);
+ if (!sleep)
+ return;
+ }
atomic_set(&conn->conn_logout_remove, 0);
complete(&conn->conn_logout_comp);
@@ -4440,8 +4443,11 @@ static void iscsit_logout_post_handler_samecid(
{
int sleep = 1;
- if (!conn->conn_transport->rdma_shutdown)
+ if (!conn->conn_transport->rdma_shutdown) {
sleep = cmpxchg(&conn->tx_thread_active, true, false);
+ if (!sleep)
+ return;
+ }
atomic_set(&conn->conn_logout_remove, 0);
complete(&conn->conn_logout_comp);
--
1.9.1
Re: [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Am Freitag, den 02.06.2017, 09:38 +0200 schrieb Richard Weinberger:
> Thomas,
>
> Am 02.06.2017 um 07:49 schrieb Florian Fainelli:
> > > the put_fp_registers fails with errno 4 if I recall correctly.
> > >
> > > I didn't investigate yet further, why the the xstate ptrace call
> > > fails.
> >
> > Which of the branches is put_fp_registers() taking? The
> > restore_fpx_registers() or restore_fp_registers()? 4 would be
> > EINTR...
> > What kernel version is used on your host running the UML binary?
>
> Another question, is this x86_64 UML on a x86_64 host?
yes,
and strace shows this:
ptrace(PTRACE_CONT, 21664, NULL, SIG_0) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_TRAPPED, si_pid=21664, si_uid=1000,
si_status=SIGTRAP, si_utime=0, si_stime=0} ---
wait4(21664, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], WSTOPPED|__WALL,
NULL) = 21664
ptrace(PTRACE_SETREGS, 21664, NULL, 0x60f7fa20) = 0
ptrace(PTRACE_CONT, 21664, NULL, SIG_0) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_TRAPPED, si_pid=21664, si_uid=1000,
si_status=SIGTRAP, si_utime=0, si_stime=0} ---
wait4(21664, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], WSTOPPED|__WALL,
NULL) = 21664
ptrace(PTRACE_SETREGS, 21664, NULL, 0xb18bc4e0) = 0
ptrace(PTRACE_SETREGSET, 21664, NT_X86_XSTATE, [{iov_base=0xb18bc5b8,
iov_len=832}]) = -1 EFAULT (Bad address)
ioctl(1, TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
don't know why gdb shows errno as 4...
> Or i386 on x86_64, i386 on i386?
>
> Thanks,
> //richard
Re: [PATCH v7 00/23] FSI device driver implementation
On Sat, 3 Jun 2017 19:05:10 +0900
Greg KH wrote:
> On Wed, May 31, 2017 at 12:17:05PM -0500, Christopher Bostic wrote:
> > Hi Greg,
> >
> > Are there any further changes you require for this patch set? This has been
> > extensively tested internally and all is working as expected. Would it be
> > possible to move forward with integration in the near future? Any input
> > would be appreciated.
>
> Sorry for the delay. I just tried applying this to my tree, but got the
> following build warnings, and then errors:
>
> In file included from ./include/trace/define_trace.h:95:0,
> from ./include/trace/events/fsi.h:127,
> from drivers/fsi/fsi-core.c:27:
> ./include/trace/events/fsi.h: In function ‘trace_raw_output_fsi_master_write’:
> ./include/trace/events/fsi.h:58:12: warning: field width specifier ‘*’
> expects argument of type ‘int’, but argument 8 has type ‘size_t {aka long
> unsigned int}’ [-Wformat=]
> TP_printk("fsi%d:%02d:%02d %08x[%zd] <= {%*ph}",
>From patch 16/23:
+TRACE_EVENT(fsi_master_write,
+ TP_PROTO(const struct fsi_master *master, int link, int id,
+ uint32_t addr, size_t size, const void *data),
+ TP_ARGS(master, link, id, addr, size, data),
+ TP_STRUCT__entry(
+ __field(int,master_idx)
+ __field(int,link)
+ __field(int,id)
+ __field(__u32, addr)
+ __field(size_t, size)
+ __field(__u32, data)
+ ),
+ TP_fast_assign(
+ __entry->master_idx = master->idx;
+ __entry->link = link;
+ __entry->id = id;
+ __entry->addr = addr;
+ __entry->size = size;
+ __entry->data = 0;
+ memcpy(&__entry->data, data, size);
+ ),
+ TP_printk("fsi%d:%02d:%02d %08x[%zd] <= {%*ph}",
+ __entry->master_idx,
+ __entry->link,
+ __entry->id,
+ __entry->addr,
+ __entry->size,
+ __entry->size, &__entry->data
+ )
+);
Looks like the second __entry->size, probably needs a type cast.
Would something like:
__entry->size,
(int)__entry->size, &__entry->data
work?
I haven't looked at the others, but I'm guessing they are probably
similar issues.
-- Steve
> ^
> ./include/trace/trace_events.h:343:22: note: in definition of macro
> ‘DECLARE_EVENT_CLASS’
> trace_seq_printf(s, print); \
> ^
> ./include/trace/trace_events.h:65:9: note: in expansion of macro ‘PARAMS’
> PARAMS(print)); \
> ^~
> ./include/trace/events/fsi.h:37:1: note: in expansion of macro ‘TRACE_EVENT’
> TRACE_EVENT(fsi_master_write,
> ^~~
> ./include/trace/events/fsi.h:58:2: note: in expansion of macro ‘TP_printk’
> TP_printk("fsi%d:%02d:%02d %08x[%zd] <= {%*ph}",
> ^
> In file included from ./include/trace/trace_events.h:377:0,
> from ./include/trace/define_trace.h:95,
> from ./include/trace/events/fsi.h:127,
> from drivers/fsi/fsi-core.c:27:
> ./include/trace/events/fsi.h:58:44: note: format string is defined here
> TP_printk("fsi%d:%02d:%02d %08x[%zd] <= {%*ph}",
>~^~
> In file included from ./include/trace/define_trace.h:95:0,
> from ./include/trace/events/fsi.h:127,
> from drivers/fsi/fsi-core.c:27:
> ./include/trace/events/fsi.h: In function
> ‘trace_raw_output_fsi_master_rw_resul
> ’:
> ./include/trace/events/fsi.h:95:12: warning: field width specifier ‘*’
> expects argument of type ‘int’, but argument 9 has type ‘size_t {aka long
> unsigned int}’ [-Wformat=]
> TP_printk("fsi%d:%02d:%02d %08x[%zd] %s {%*ph} ret %d",
> ^
> ./include/trace/trace_events.h:343:22: note: in definition of macro
> ‘DECLARE_EVENT_CLASS’
> trace_seq_printf(s, print); \
> ^
> ./include/trace/trace_events.h:65:9: note: in expansion of macro ‘PARAMS’
> PARAMS(print)); \
> ^~
> ./include/trace/events/fsi.h:68:1: note: in expansion of macro ‘TRACE_EVENT’
> TRACE_EVENT(fsi_master_rw_result,
> ^~~
> ./include/trace/events/fsi.h:95:2: note: in expansion of macro ‘TP_printk’
> TP_printk("fsi%d:%02d:%02d %08x[%zd] %s {%*ph} ret %d",
> ^
> In file included from ./include/trace/trace_events.h:377:0,
> from ./include/trace/define_trace.h:95,
> from ./include/trace/events/fsi.h:127,
> from drivers/fsi/fsi-core.c:27:
> ./include/trace/events/fsi.h:95:44: note: format string is defined here
> TP_printk("fsi%d:%02d:%02d %08x[%zd] %s {%*ph} ret %d",
>~^~
> CHK include/generated/uapi/linux/version.h
> GEN .version
> CHK include/generated/compile.h
> UPD
I am Talent Scout For Sony Pictures Animation
Dear Talented, I am Talent Scout For Sony Pictures Animation, Present Sony Pictures Animation Movies a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story of Peter Rabbit (Peter Rabbit 2018) The Movie is Currently Filming (In Production) Please Note That There Will Be No Auditions, Traveling or Any Special / Professional Acting Skills, Since the Production of This Movie Will Be Done with our State of Art Computer -Generating Imagery Equipment. We Are Prepared to Pay the Total Sum of $560,000.00 USD. For More Information/Understanding, Please Write us on the E-Mail Below. CONTACT EMAIL: sonyp...@usa.com All Reply to: sonyp...@usa.com Note: Only the Response send to this mail will be Given a Prior Consideration. Talent Scout Becky Miles
Re: [PATCH] firmware: dmi: Check DMI structure length
On Fri, 2 Jun 2017 21:45:37 +0300, Andy Shevchenko wrote: > On Fri, Jun 2, 2017 at 9:40 PM, Jean Delvare wrote: > > On Thu, 1 Jun 2017 19:06:36 +0300, Andy Shevchenko wrote: > >> Your commit message should answer to the question why and what. > >> You didn't put it there. > >> Moreover, the change above per se doesn't belong to this — one logical > >> change per patch. > > > > I'm confused. These changes totally belong to this patch. They belong > > so much to it, that's the very reason why they are not described > > separately in the commit message. > > > > The purpose of the patch is to check that the records are large enough > > to contain the fields we need to access. Setting a pointer beyond the > > end of the record _before_ performing that check makes no sense. > > > > I did not include these changes as performance optimizations, I > > included them because they make the code conceptually correct. It's > > even clearer for the last instance, as we are dereferencing the pointer > > immediately, but in my opinion, even setting a pointer to a location > > which may not exist is equally wrong and confusing for the reader. > > That's why I moved that code after the length checks. > > You are talking here explicitly about third case which I agreed on. > > The two first ones are not the same. > You didn't dereference them before check since your check is not > against pointer. > > So, basically it means you are checking pointer _indirectly_. Correct. > I think we already spent too much time on this one. Agreed. > If you wish to leave your changes, update commit message accordingly. No. -- Jean Delvare SUSE L3 Support
Re: [PATCH 1/5] sparc: simplify
From: Christoph Hellwig Date: Sat, 3 Jun 2017 21:00:58 +0200 > There is no need for the forward declaration of compat_siginfo provided > here. We can't yet use the generic header as we need to pull in the > sparc-specific version of the uapi , but this prepares > for removing the non-uapi entirely. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller
[PATCH] target: Fix kref->refcount underflow in transport_cmd_finish_abort
From: Nicholas Bellinger
This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED
when a fabric driver drops it's second reference from below the
target_core_tmr.c based callers of transport_cmd_finish_abort().
Recently with the conversion of kref to refcount_t, this bug was
manifesting itself as:
[705519.601034] refcount_t: underflow; use-after-free.
[705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run:
20116.512 msecs
[705539.719111] [ cut here ]
[705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184
refcount_sub_and_test+0x33/0x51
Since the original kref atomic_t based kref_put() didn't check for
underflow and only invoked the final callback when zero was reached,
this bug did not manifest in practice since all se_cmd memory is
using preallocated tags.
To address this, go ahead and propigate the existing return from
transport_put_cmd() up via transport_cmd_finish_abort(), and
change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
callers to only do their local target_put_sess_cmd() if necessary.
Reported-by: Bart Van Assche
Cc: Mike Christie
Cc: Hannes Reinecke
Cc: Christoph Hellwig
Cc: Himanshu Madhani
Cc: Sagi Grimberg
Cc: sta...@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_internal.h | 2 +-
drivers/target/target_core_tmr.c | 16
drivers/target/target_core_transport.c | 9 ++---
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/target/target_core_internal.h
b/drivers/target/target_core_internal.h
index 9ab7090..0912de7 100644
--- a/drivers/target/target_core_internal.h
+++ b/drivers/target/target_core_internal.h
@@ -136,7 +136,7 @@ struct se_node_acl *core_tpg_add_initiator_node_acl(struct
se_portal_group *tpg,
void release_se_kmem_caches(void);
u32scsi_get_new_index(scsi_index_t);
void transport_subsystem_check_init(void);
-void transport_cmd_finish_abort(struct se_cmd *, int);
+inttransport_cmd_finish_abort(struct se_cmd *, int);
unsigned char *transport_dump_cmd_direction(struct se_cmd *);
void transport_dump_dev_state(struct se_device *, char *, int *);
void transport_dump_dev_info(struct se_device *, struct se_lun *,
diff --git a/drivers/target/target_core_tmr.c b/drivers/target/target_core_tmr.c
index dce1e1b..13f47bf 100644
--- a/drivers/target/target_core_tmr.c
+++ b/drivers/target/target_core_tmr.c
@@ -75,7 +75,7 @@ void core_tmr_release_req(struct se_tmr_req *tmr)
kfree(tmr);
}
-static void core_tmr_handle_tas_abort(struct se_cmd *cmd, int tas)
+static int core_tmr_handle_tas_abort(struct se_cmd *cmd, int tas)
{
unsigned long flags;
bool remove = true, send_tas;
@@ -91,7 +91,7 @@ static void core_tmr_handle_tas_abort(struct se_cmd *cmd, int
tas)
transport_send_task_abort(cmd);
}
- transport_cmd_finish_abort(cmd, remove);
+ return transport_cmd_finish_abort(cmd, remove);
}
static int target_check_cdb_and_preempt(struct list_head *list,
@@ -184,8 +184,8 @@ void core_tmr_abort_task(
cancel_work_sync(&se_cmd->work);
transport_wait_for_tasks(se_cmd);
- transport_cmd_finish_abort(se_cmd, true);
- target_put_sess_cmd(se_cmd);
+ if (!transport_cmd_finish_abort(se_cmd, true))
+ target_put_sess_cmd(se_cmd);
printk("ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for"
" ref_tag: %llu\n", ref_tag);
@@ -281,8 +281,8 @@ static void core_tmr_drain_tmr_list(
cancel_work_sync(&cmd->work);
transport_wait_for_tasks(cmd);
- transport_cmd_finish_abort(cmd, 1);
- target_put_sess_cmd(cmd);
+ if (!transport_cmd_finish_abort(cmd, 1))
+ target_put_sess_cmd(cmd);
}
}
@@ -380,8 +380,8 @@ static void core_tmr_drain_state_list(
cancel_work_sync(&cmd->work);
transport_wait_for_tasks(cmd);
- core_tmr_handle_tas_abort(cmd, tas);
- target_put_sess_cmd(cmd);
+ if (!core_tmr_handle_tas_abort(cmd, tas))
+ target_put_sess_cmd(cmd);
}
}
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 6025935..f1b3a46 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -651,9 +651,10 @@ static void transport_lun_remove_cmd(struct se_cmd *cmd)
percpu_ref_put(&lun->lun_ref);
}
-void transport_cmd_finish_abort(struct se_cmd *cmd, int remove)
+int transport_cmd_finish_abort(struct se_cmd *cmd, int remove)
{
bool ack_kref = (cmd->se_cmd_flags & SCF_ACK_KREF);
+ int ret = 0;
if (cmd->se_cmd_flags & SCF_SE_LUN_CMD)
transport_lun_remove_cmd(cmd);
@@ -665,9 +666,1
Re: [linux-next / tty] possible circular locking dependency detected
On 06/03/17 11:34, Greg Kroah-Hartman wrote:
On Mon, May 29, 2017 at 12:43:39PM +0200, Vegard Nossum wrote:
On 05/22/17 12:27, Vegard Nossum wrote:
On 05/22/17 12:24, Greg Kroah-Hartman wrote:
On Mon, May 22, 2017 at 04:39:43PM +0900, Sergey Senozhatsky wrote:
Hello,
[ 1274.378287] ==
[ 1274.378289] WARNING: possible circular locking dependency detected
[ 1274.378290]
4.12.0-rc1-next-20170522-dbg-7-gc09b2ab28b74-dirty #1317 Not
tainted
[ 1274.378291] --
[ 1274.378293] kworker/u8:5/111 is trying to acquire lock:
[ 1274.378294] (&buf->lock){+.+...}, at: []
tty_buffer_flush+0x34/0x88
[ 1274.378300]
but task is already holding lock:
[ 1274.378301] (&o_tty->termios_rwsem/1){..}, at:
[] isig+0x47/0xd2
[ 1274.378307]
which lock already depends on the new lock.
Any hint as to what you were doing when this happened?
Does this also show up in 4.11?
It's my patch "tty: fix port buffer locking" :-/
At a glance, looks related to pty taking the lock on the other side in a
different order. I'll have a closer look.
I can reproduce the lockdep report locally on v4.12-rc3. Looking at it now.
Any ideas? Or should I just revert the original patch?
I think we must revert it for now, as I can easily reproduce not just
the lockdep warning but actual hangs. It seems I missed some code paths
when I worked the original patch.
I'm working on a fix.
Vegard
Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional
On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote:
> On Fri, 2 Jun 2017, Paul E. McKenney wrote:
>
> > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote:
> > > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote:
> > > > On Fri, 12 May 2017, Paul E. McKenney wrote:
> >
> > [ . . . ]
> >
> > > > No. "Available in mainline" is the name of the game for all I do. If
> > > > it
> > > > can't be made acceptable for mainline then it basically has no chance
> > > > of
> > > > gaining traction and becoming generally useful. My approach is
> > > > therefore
> > > > to always find solutions that can be maintained upstream and
> > > > contributed
> > > > to with minimal fuss by anyone.
> > >
> > > OK, then wish me luck. ;-)
> >
> > And still quite a bit of back and forth. How are things with tty?
> >
> > One question that came up -- what sort of SoCs are you targeting?
> > A number of people are insisting that smartphone SoCs with 256M DRAM
> > are the minimal systems of the future. This seems unlikely to me,
> > given the potential for extremely cheap SoCs with EDRAM or some such,
> > but figured I should ask what you are targeting.
>
> I'm targetting 256 *kilobytes* of RAM. Most likely SRAM. That's not for
> smart phones but really cheap IoT devices. That's the next area for
> (trimmed down) Linux to conquer. Example targets are STM32 chips.
>
> Please see the following for the rationale and how to get there:
>
> https://lwn.net/Articles/721074/
>
> http://www.mail-archive.com/search?l=mid&q=alpine.LFD.2.20.1703241215540.2304%40knanqh.ubzr
Ah, thank you for the reminder. I did read that article, but somehow
got a few megabytes stuck in my head instead of the correct quarter meg.
Anyway, don't look now, but Tiny {S,}RCU just might live on, for a bit
longer, anyway.
Thanx, Paul
Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes
On Sat, Jun 3, 2017 at 9:34 PM, Greg Kroah-Hartman
wrote:
> On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote:
>> On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman
>> wrote:
>> > On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
>> >> From: Peter Rosin
>> >>
>> >> Hi Greg,
>> >>
>> >> Philipp found problems in v14 with using a mutex for locking that was
>> >> the outcome of the review for v13, so I'm now using a semaphore instead
>> >> of the rwsem that was in v13. That at least got rid of the scary call
>> >> to downgrade_write. However, I'm still unsure about what you actually
>> >> meant with your comment about lack of sparse markings [1]. I did add
>> >> __must_check to the funcs that selects the mux, but I've got this
>> >> feeling that this is not what you meant?
>> >
>> > I thought there was a way to mark a function as requiring a lock be held
>> > when it is being called. Does sparse not support that anymore?
>>
>> sparse still support these annotations, of course.
>> In this case, I suppose you're talking about '__must_hold()' which
>> *must* be used instead of a pair of '__releases()' + '__acquires()'
>> when the lock is help on function entry and exit.
>
> Ah, yes, that's what I was thinking of. I don't know if sparse can
> track things like this across an exported symbol, so I doubt it really
> will help here. Sorry for the noise.
No problem, I'm glad to help for sparse related things.
I didn't saw the code in question because the lkml.org link Peter
gave didn't work for me and I don't know much about exported symbols
(but I think the sole effect is to add some data in some symbol table).
But these annotations just work based on the declarations, very much
like type checking. So if you have something in scope like the following:
void do_stuff_locked(struct s *ptr) __must_hold(*ptr);
...
void do_stuff_unlocked(struct s *ptr)
{
...
do_stuff_locked(ptr);// will warn
...
}
You will have a warning from sparse unless the code preceding and following
the call to do_stuff_locked() lock & then unlock 'ptr', generaly
indirectly by a pair
of functions, the one before with an '__acquires()' in its declaration
the one after
with a '__releases()' in its declaration:
void lock_stuff(struct s *ptr) __acquires(*ptr);
void unlock_stuff(struct s *ptr) __releases(*ptr);
void do_stuff_unlocked(struct s *ptr)
{
lock_stuff(ptr);
do_stuff_locked(ptr);// won't warn
unlock_stuff(ptr);
}
Regards,
-- Luc
Re: [PATCH] virtio_net: lower limit on buffer size
On 06/02/2017 11:25 PM, J. Bruce Fields wrote:
commit d85b758f72b0 "virtio_net: fix support for small rings"
Commit d85b758f72b0 ("virtio_net: fix support for small rings")
was supposed to increase the buffer size for small rings
but had an unintentional side effect of decreasing
it for large rings. This seems to break some setups -
it's not yet clear why, but increasing buffer size
back to what it was before helps.
Fixes: d85b758f72b0 "virtio_net: fix support for small rings"
Fixes: d85b758f72b0 ("virtio_net: fix support for small rings")
I may be bikeshedding, but, personally I never do the parens--they're
redundant given the quotes, and space is often tight.
Just see Documetation/process/submitting-patches.rst.
MBR, Sergei
[PATCH 3/3] ARM: pxa: Delete an error message for a failed memory allocation in pxa3xx_u2d_probe()
From: Markus Elfring
Date: Sat, 3 Jun 2017 21:46:26 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
arch/arm/mach-pxa/pxa3xx-ulpi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-pxa/pxa3xx-ulpi.c b/arch/arm/mach-pxa/pxa3xx-ulpi.c
index 13f9909ac8bf..60cb59a7ebd1 100644
--- a/arch/arm/mach-pxa/pxa3xx-ulpi.c
+++ b/arch/arm/mach-pxa/pxa3xx-ulpi.c
@@ -290,7 +290,5 @@ static int pxa3xx_u2d_probe(struct platform_device *pdev)
- if (!u2d) {
- dev_err(&pdev->dev, "failed to allocate memory\n");
+ if (!u2d)
return -ENOMEM;
- }
u2d->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(u2d->clk)) {
--
2.13.0
[PATCH 2/3] ARM: pxa: Improve a size determination in pxa3xx_u2d_probe()
From: Markus Elfring
Date: Sat, 3 Jun 2017 21:43:11 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring
---
arch/arm/mach-pxa/pxa3xx-ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/pxa3xx-ulpi.c b/arch/arm/mach-pxa/pxa3xx-ulpi.c
index eba595fac8ca..13f9909ac8bf 100644
--- a/arch/arm/mach-pxa/pxa3xx-ulpi.c
+++ b/arch/arm/mach-pxa/pxa3xx-ulpi.c
@@ -286,5 +286,5 @@ static int pxa3xx_u2d_probe(struct platform_device *pdev)
struct resource *r;
int err;
- u2d = kzalloc(sizeof(struct pxa3xx_u2d_ulpi), GFP_KERNEL);
+ u2d = kzalloc(sizeof(*u2d), GFP_KERNEL);
if (!u2d) {
--
2.13.0
[PATCH 1/3] ARM: pxa: Delete an error message for a failed memory allocation in pxa_pm_init()
From: Markus Elfring
Date: Sat, 3 Jun 2017 21:34:48 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
arch/arm/mach-pxa/pm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-pxa/pm.c b/arch/arm/mach-pxa/pm.c
index e7450fb49d24..f2237f471750 100644
--- a/arch/arm/mach-pxa/pm.c
+++ b/arch/arm/mach-pxa/pm.c
@@ -110,7 +110,5 @@ static int __init pxa_pm_init(void)
- if (!sleep_save) {
- printk(KERN_ERR "failed to alloc memory for pm save\n");
+ if (!sleep_save)
return -ENOMEM;
- }
suspend_set_ops(&pxa_pm_ops);
return 0;
--
2.13.0
[PATCH 0/3] ARM-pxa: Adjustments for two function implementations
From: Markus Elfring Date: Sat, 3 Jun 2017 22:02:34 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an error message for a failed memory allocation in pxa_pm_init() Improve a size determination in pxa3xx_u2d_probe() Delete an error message for a failed memory allocation in pxa3xx_u2d_probe() arch/arm/mach-pxa/pm.c | 4 +--- arch/arm/mach-pxa/pxa3xx-ulpi.c | 6 ++ 2 files changed, 3 insertions(+), 7 deletions(-) -- 2.13.0
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver
Hi! > >>>+ /* Auto/manual exposure */ > >>>+ ctrls->auto_exp = v4l2_ctrl_new_std_menu(hdl, ops, > >>>+ V4L2_CID_EXPOSURE_AUTO, > >>>+ V4L2_EXPOSURE_MANUAL, 0, > >>>+ V4L2_EXPOSURE_AUTO); > >>>+ ctrls->exposure = v4l2_ctrl_new_std(hdl, ops, > >>>+ V4L2_CID_EXPOSURE_ABSOLUTE, > >>>+ 0, 65535, 1, 0); > >> > >>Is exposure_absolute supposed to be in microseconds...? > > > >Yes. > > According to the docs V4L2_CID_EXPOSURE_ABSOLUTE is in 100 usec units. > > OTOH V4L2_CID_EXPOSURE has no defined unit, so it's a better fit IMO. > >Way more drivers appear to be using EXPOSURE than EXPOSURE_ABSOLUTE, too. > > Done, switched to V4L2_CID_EXPOSURE. It's true, this control is not > taking 100 usec units, so unit-less is better. Thanks. If you know the units, it would be of course better to use right units... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: WMI and Kernel:User interface
On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman wrote: > On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote: > > Linus and Greg, > > > > We are in the process of redesigning the Windows Management Instrumentation > > (WMI) [1] system in the kernel. WMI is the Microsoft implementation of > > Web-Based > > Enterprise Management (WBEM). We are looking to provide WMI access to > > userspace, > > while allowing the kernel to filter requests that conflict with its own > > usage. > > We'd like your take on how this approach relates to our commitment to not > > break > > userspace. > > > > For this discussion, we are specifically referring to ACPI PNP0C14 WMI > > devices, consisting of a GUID and a set of methods and events, as well as a > > precompiled intermediate description of the methods and arguments (MOF). > > Exposed > > to userspace, these methods provide for BIOS interaction and are used for > > system > > management as well as LEDs, hot keys, radio switches, etc. There is vendor > > interest in achieving feature parity with Windows by exposing WMI methods to > > userspace for system management. > > > > While it appears WMI intended to be accessed from userspace, we have > > made use of it in the kernel to support various laptop features by > > connecting > > the WMI methods to other subsystems, notably input, leds, and rfkill [2]. > > The > > challenge is continuing to use WMI for these platform features, while > > allowing > > userspace to use it for system management tasks. Unfortunately, the WMI > > methods > > are not guaranteed to be split up along granular functional lines, and we > > will > > certainly face situations where the same GUID::METHOD_ID will be needed for > > a > > kernel feature (say LED support) as well as a system management task. > > > > To address this, I have proposed [3] that exporting WMI be opt-in, only > > done at > > the request of and in collaboration with a vendor, with the kernel platform > > driver given the opportunity to filter requests. This filtering would need > > to be > > at the method and argument inspection level, such as checking for specific > > bits > > in the input buffer, and rejecting the request if they conflict with an in > > kernel usage (that's worst case, in some cases just GUID or method ID could > > be > > sufficient). > > > > Because the kernel and the platform drivers are under continual > > development, and > > new systems appear regularly, we will encounter necessary changes to the > > platform driver WMI request filters. These changes could be considered a > > change > > to the kernel provided WMI interface to userspace. For example, we could > > regularly accept a call to $GUID::$METHOD_ID with bit 4 of the buffer set, > > and > > later deny the call when we determine it interferes with kernel usage. > > > > In your view, is it acceptable to provide a chardev interface, for example, > > exposing WMI methods to userspace, with the understanding that the kernel > > may > > choose to filter certain requests which conflict with its own use? And that > > this > > filtering may change as new features are added to the platform drivers? > > So, for example, if a new driver for a "brightness key" were added to > the kernel, all of a sudden the "raw" access to the wmi data through the > chardev would filtered away by the kernel and not seen by userspace? > > Why would you want to do that? What's wrong with providing "raw" access > through a chardev, and the current in-kernel access as well at the same > time? > > I don't really understand what would "break" over time here. > Just a bump now that we're out of the merge window in case either Greg or Linus care to follow up with the responses to this. To Greg's last point - any kernel state that is built up in conjunction with the WMI interface could be invalidated by a userspace application. It may or may not be recoverable, depending on the WMI implementation. This would be true for multiple WMI userspace applications as well, and I suppose the question is, do we defend the kernel drivers against this, or do we consider the kernel drivers on equal footing with WMI applications, and say "don't do that then" when some combination of apps and drivers don't play well together? > thanks, > > greg k-h > -- Darren Hart VMware Open Source Technology Center
Re: [PATCH 3.16 144/212] batman-adv: Fix double free during fragment merge error
On Thu, 2017-06-01 at 18:44 +0200, Sven Eckelmann wrote:
> On Donnerstag, 1. Juni 2017 16:43:16 CEST Ben Hutchings wrote:
> > 3.16.44-rc1 review patch. If anyone has any objections, please let me know.
>
> It looks to me like there are problems with this backport. The surrounding
> code has to be adjusted slightly further to avoid additional problems.
Thanks for the review.
[...]
> It is not really easy to see but this change will introduce a new double free
> for kernels older than v4.10. The relevant commit is b91a2543b4c1 ("batman-
> adv: Consume skb in receive handlers"). This was discussed in following gluon
> ticket https://github.com/freifunk-gluon/gluon/issues/1083 (just in case you
> are interested about the details)
>
> Following change must therefore be added to this patch on older kernels:
>
> --- a/net/batman-adv/routing.c
> +++ b/net/batman-adv/routing.c
> @@ -961,6 +961,12 @@ int batadv_recv_frag_packet(struct sk_buff *skb,
> batadv_inc_counter(bat_priv, BATADV_CNT_FRAG_RX);
> batadv_add_counter(bat_priv, BATADV_CNT_FRAG_RX_BYTES, skb->len);
>
> + /* batadv_frag_skb_buffer will always consume the skb and
> + * the caller should therefore never try to free the
> + * skb after this point
> + */
> + ret = NET_RX_SUCCESS;
> +
> /* Add fragment to buffer and merge if possible. */
> if (!batadv_frag_skb_buffer(&skb, orig_node_src))
> goto out;
>
> You can also remove the same instruction which appears later in this function.
OK, I'll squash this into the patch.
Ben.
--
Ben Hutchings
Experience is directly proportional to the value of equipment
destroyed.
- Carolyn
Scheppner
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver
On 06/01/2017 01:26 AM, Sakari Ailus wrote: Hi Pavel, On Wed, May 31, 2017 at 09:58:21PM +0200, Pavel Machek wrote: Hi! +/* min/typical/max system clock (xclk) frequencies */ +#define OV5640_XCLK_MIN 600 +#define OV5640_XCLK_MAX 2400 + +/* + * FIXME: there is no subdev API to set the MIPI CSI-2 + * virtual channel yet, so this is hardcoded for now. + */ +#define OV5640_MIPI_VC 1 Can the FIXME be fixed? Yes, but it's quite a bit of work. It makes sense to use a static virtual channel for now. A patchset which is however incomplete can be found here: https://git.linuxtv.org/sailus/media_tree.git/log/?h=vc> For what it's worth, all other devices use virtual channel zero for image data and so should this one. Actually no. The CSI2IPU gasket in i.MX6 quad sends virtual channel 0 streams to IPU1-CSI0. But input to IPU1-CSI0 is also muxed with parallel bus cameras. So if vc0 were chosen instead, platforms that support parallel cameras to IPU1-CSI0 (SabreLite, SabreSD) would not be able to use them concurrently with a MIPI CSI-2 source to IPU1-CSI1. So I prefer to use static channel 1 to support those platforms. I could convert this to a module parameter however, until a virtual channel selection subdev API becomes available, at which point that would have to be stripped. +/* + * image size under 1280 * 960 are SUBSAMPLING -> Image + * image size upper 1280 * 960 are SCALING above? done. +/* + * FIXME: all of these register tables are likely filled with + * entries that set the register to their power-on default values, + * and which are otherwise not touched by this driver. Those entries + * should be identified and removed to speed register load time + * over i2c. + */ load->loading? Can the FIXME be fixed? That's a lot of work, and risky work at that. If someone could take this on (strip out power-on default values from the tables), I'd be grateful, but I don't have the time. For now at least, these registers sets work fine. + /* Auto/manual exposure */ + ctrls->auto_exp = v4l2_ctrl_new_std_menu(hdl, ops, +V4L2_CID_EXPOSURE_AUTO, +V4L2_EXPOSURE_MANUAL, 0, +V4L2_EXPOSURE_AUTO); + ctrls->exposure = v4l2_ctrl_new_std(hdl, ops, + V4L2_CID_EXPOSURE_ABSOLUTE, + 0, 65535, 1, 0); Is exposure_absolute supposed to be in microseconds...? Yes. According to the docs V4L2_CID_EXPOSURE_ABSOLUTE is in 100 usec units. OTOH V4L2_CID_EXPOSURE has no defined unit, so it's a better fit IMO. Way more drivers appear to be using EXPOSURE than EXPOSURE_ABSOLUTE, too. Done, switched to V4L2_CID_EXPOSURE. It's true, this control is not taking 100 usec units, so unit-less is better. Steve
Fast Approval in 1-2 Hours.
We provide PERSONAL and BUSINESS assistance No Deposit when you apply Loan with us!! , To Ease Your Financial Burden. -Easy Apply -Flexible Package -Fast Approval in 1-2 Hours. Email: quickfinac...@qq.com
Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes
On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote: > On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman > wrote: > > On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote: > >> From: Peter Rosin > >> > >> Hi Greg, > >> > >> Philipp found problems in v14 with using a mutex for locking that was > >> the outcome of the review for v13, so I'm now using a semaphore instead > >> of the rwsem that was in v13. That at least got rid of the scary call > >> to downgrade_write. However, I'm still unsure about what you actually > >> meant with your comment about lack of sparse markings [1]. I did add > >> __must_check to the funcs that selects the mux, but I've got this > >> feeling that this is not what you meant? > > > > I thought there was a way to mark a function as requiring a lock be held > > when it is being called. Does sparse not support that anymore? > > sparse still support these annotations, of course. > In this case, I suppose you're talking about '__must_hold()' which > *must* be used instead of a pair of '__releases()' + '__acquires()' > when the lock is help on function entry and exit. Ah, yes, that's what I was thinking of. I don't know if sparse can track things like this across an exported symbol, so I doubt it really will help here. Sorry for the noise. thanks, greg k-h
Re: [PATCH] platform/x86: dell-rbtn: Improve explanation about DELLABC6
On Sat, May 27, 2017 at 07:27:19PM +0300, Andy Shevchenko wrote: > On Sat, May 27, 2017 at 8:16 AM, Darren Hart wrote: > > From: Andy Lutomirski > > > > According to Mario at Dell, the DELLABC6 device should not be used on a > > Linux system. It also conflicts with Intel-HID and its interactions with > > Network Manager. Document that we are aware of the device, but that we > > are intentionally ignoring it. > > > > Pali made a good point. > Otherwise, FWIW: > Reviewed-by: Andy Shevchenko Agreed, updated to remove specific mention of NetworkManager. Thanks. -- Darren Hart VMware Open Source Technology Center
Sleeping BUG in khugepaged for i586
I recently turned on locking diagnostics for a Dell Latitude D600 laptop, which
requires a 32-bit kernel. In the log I found the following:
BUG: sleeping function called from invalid context at mm/khugepaged.c:655
in_atomic(): 1, irqs_disabled(): 0, pid: 20, name: khugepaged
1 lock held by khugepaged/20:
#0: (&mm->mmap_sem){++}, at: []
collapse_huge_page.isra.47+0x439/0x1240
CPU: 0 PID: 20 Comm: khugepaged Tainted: GW
4.12.0-rc1-wl-12125-g952a068 #80
Hardware name: Dell Computer Corporation Latitude D600
/03U652, BIOS A05 05/29/2003
Call Trace:
dump_stack+0x76/0xb2
___might_sleep+0x174/0x230
collapse_huge_page.isra.47+0xacf/0x1240
khugepaged_scan_mm_slot+0x41e/0xc00
? _raw_spin_lock+0x46/0x50
khugepaged+0x277/0x4f0
? prepare_to_wait_event+0xe0/0xe0
kthread+0xeb/0x120
? khugepaged_scan_mm_slot+0xc00/0xc00
? kthread_create_on_node+0x30/0x30
ret_from_fork+0x21/0x30
I have no idea when this problem was introduced. Of course, I will test any
proposed fixes.
Thanks,
Larry
