USB problems since 2.4.2
Kernel: 2.4.2 - latest (2.4.3-ac12) Platform: x86 on mangled Slack7.1 Hardware: MSI 694D Pro-AR ( http://www.msicomputer.com/products/detail.asp?ProductID=150 ) Problem: USB devices timeout on address assignment. Course thats with the non JE driver, with the JE driver the bus doesnt even say that anything gets connected. messages when driver loads: * usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.251 $ time 00:58:23 Apr 23 2001 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xb000, IRQ 19 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected usb-uhci.c: USB UHCI at I/O 0xb400, IRQ 19 usb-uhci.c: Detected 2 ports hub.c: USB new device connect on bus1/1, assigned device number 2 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected usb.c: registered new driver usblp usb.c: registered new driver dc2xx * when any device is plugged in: * hub.c: USB new device connect on bus1/1, assigned device number 4 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=4 (error=-110) hub.c: USB new device connect on bus1/1, assigned device number 5 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=5 (error=-110) * www.mammoth.org/~skulcap **BEGIN GEEK CODE BLOCK "Sometimes, if you're perfectly * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- still, you can hear the virgin * W+(++) N++ o+ K- w--(---) O- M- V- PS-- weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++ --DreamTheater, "Lines in the Sand" * G e h+ r-- y- (www.geekcode.com) **END GEEK CODE BLOCK** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB problems since 2.4.2
> On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote: > > Kernel: 2.4.2 - latest (2.4.3-ac12) > > Platform: x86 on mangled Slack7.1 > > Hardware: MSI 694D Pro-AR > > ( http://www.msicomputer.com/products/detail.asp?ProductID=150 ) > > > > Problem: USB devices timeout on address assignment. Course thats with the > > non JE driver, with the JE driver the bus doesnt even say that anything > > gets connected. > > > > when any device is plugged in: > > * > > hub.c: USB new device connect on bus1/1, assigned device number 4 > > usb_control/bulk_msg: timeout > > usb.c: USB device not accepting new address=4 (error=-110) > > hub.c: USB new device connect on bus1/1, assigned device number 5 > > usb_control/bulk_msg: timeout > > usb.c: USB device not accepting new address=5 (error=-110) > > * > > Can you try booting your kernel with the "noapic" option and see if it > still happens? > DING DING DING! that did the trick. Thnx! www.mammoth.org/~skulcap **BEGIN GEEK CODE BLOCK "Sometimes, if you're perfectly * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- still, you can hear the virgin * W+(++) N++ o+ K- w--(---) O- M- V- PS-- weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++ --DreamTheater, "Lines in the Sand" * G e h+ r-- y- (www.geekcode.com) **END GEEK CODE BLOCK** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
usb dc2xx quirk
Kernel Version: 2.4.0-test11 - 2.4.0-prerelease Platform: ix86 (PIII) Problem Hardware: Kodac DC280, firmware 1.01 Ever since test10 or after, removing my dc280 from the usb bus causes khubd to crash. I have tried both UHCI drivers and they produce the same effect. dmesg, syslog, messages, and .config can be found at: http://mammoth.org/~skulcap/usb-problem I have looked throug the archives and havent found anything like this, so I'm sorry if it has been covered already. Thanks in advance! mammoth.org/~skulcap **BEGIN GEEK CODE BLOCK "Sometimes, if you're perfectly * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- still, you can hear the virgin * W+(++) N++ o+ K- w--(---) O- M- V- PS-- weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++ --DreamTheater, "Lines in the Sand" * G e h+ r-- y- (www.geekcode.com) **END GEEK CODE BLOCK** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
funky tyan s2510
I have a tyan s2510 with a single pIII 800Mhz cpu and 1GB of RAM. I have been having problems with this system from the get go and cant seem to narrow down what the problem is. I have tried running 2.4.6, but the system usually doesnt last more than a day. With 2.4.2 i get a variety of kernel messages: # vs-5150: search_by_key: invalid format found in block 0. Fsck? vs-13050: reiserfs_update_sd: i/o failure occurred trying to update [59906829 0x0 SD] stat datavs-13060: reiserfs_update_sd: stat data of object [10616 10762 0x0 SD] (nlink == 1) not found (pos 6) vs-13060: reiserfs_update_sd: stat data of object [8766 9018 0x0 SD] (nlink == 1) not found (pos 0) vs-13060: reiserfs_update_sd: stat data of object [8766 8959 0x0 SD] (nlink == 1) not found (pos 12) vs-13060: reiserfs_update_sd: stat data of object [8766 8959 0x0 SD] (nlink == 1) not found (pos 12) memory.c:303: bad pmd 8524468b. memory.c:83: bad pmd 831074c0. memory.c:83: bad pmd 8524468b. memory.c:83: bad pmd 831074c0. memory.c:83: bad pmd 8524468b. memory.c:83: bad pmd 831074c0. memory.c:83: bad pmd 8524468b. memory.c:83: bad pmd 831074c0. kernel BUG at inode.c:79! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010282 eax: 001a ebx: f5e3c2a0 ecx: d99ae000 edx: esi: c027e120 edi: dc12a620 ebp: d99affa4 esp: d99aff44 ds: 0018 es: 0018 ss: 0018 Process rm (pid: 13400, stackpage=d99af000) Stack: c02301a5 c0230225 004f f5e3c2a0 c01428b6 f5e3c2a0 dc12a620 f5e3c2a0 c01413c6 f5e3c2a0 f5d1ea00 c013b1fc dc12a620 dc12a620 dc12a620 d82e c013b2d3 f5d1ea00 dc12a620 d99ae000 be82 bc48 Call Trace: [] [] [] [] [] Code: 0f 0b 83 c4 0c a1 90 09 2d c0 53 50 e8 d9 65 fe ff 83 c4 08 gcc never gets all the way through a make... it will die with a sig11, misc asm errors, or random crap. This is a serverworks chipset... i have always thought that they were a bit, you know, funny. :) Any ideas? www.mammoth.org/~skulcap **BEGIN GEEK CODE BLOCK "Sometimes, if you're perfectly * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- still, you can hear the virgin * W+(++) N++ o+ K- w--(---) O- M- V- PS-- weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++ --DreamTheater, "Lines in the Sand" * G e h+ r-- y- (www.geekcode.com) **END GEEK CODE BLOCK** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: funky tyan s2510
On Fri, 6 Jul 2001, Alan Cox wrote: > > gcc never gets all the way through a make... it will die with a > > sig11, misc asm errors, or random crap. > > If its doing that at random then suspect hardaware Thats what I thought at first, but after going through three different brands of memory and a new (slower) cpu, im not sure what to think. > > This is a serverworks chipset... i have always thought that they were > > a bit, you know, funny. :) > > Serverworks have an obscure MTRR bug in a few chips (which we handle) but > quite honestly they don't show up a lot in kernel bug reports. I actually like SW chipsets... they do some neat things... more than me at least. www.mammoth.org/~skulcap **BEGIN GEEK CODE BLOCK "Sometimes, if you're perfectly * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- still, you can hear the virgin * W+(++) N++ o+ K- w--(---) O- M- V- PS-- weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++ --DreamTheater, "Lines in the Sand" * G e h+ r-- y- (www.geekcode.com) **END GEEK CODE BLOCK** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
via82cxxx audio fun
Kernel: 2.4.4 Well, for all those people getting "audio drain" messages when trying to play audio with your via82cxxx driver try passing the "noapic" option to your kernel on bootup to see if it works. I did manage to get mine to work, but only with xmms. When I try to use other programs, like mplayer or mtv, I get these kernel messages * Assertion failed! card->ch_out.is_active,via82cxxx_audio.c,via_dsp_poll,line=2278 Assertion failed! card->ch_out.is_active,via82cxxx_audio.c,via_dsp_poll,line=2278 Assertion failed! card->ch_out.is_active,via82cxxx_audio.c,via_dsp_poll,line=2278 * The audio ends up playing very very fast... its pretty funny, but not very useful :) Programs like mpg123 still wont play anything (i assume due to the rate locked codec). Oh, and I cant get the mixer to work... with any program. Its like it isnt there. thnx in adv www.mammoth.org/~skulcap **BEGIN GEEK CODE BLOCK "Sometimes, if you're perfectly * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- still, you can hear the virgin * W+(++) N++ o+ K- w--(---) O- M- V- PS-- weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++ --DreamTheater, "Lines in the Sand" * G e h+ r-- y- (www.geekcode.com) **END GEEK CODE BLOCK** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tinyconfig x86-32 vmlinux sizes by gcc compiler version
On Thu, Dec 04, 2014 at 01:32:59PM -0800, Joe Perches wrote: > Just fyi. > > At least for x86-32, it seems later versions of gcc > are producing smaller images. > > $ size vmlinux.* >text data bss dec hex filename > 657725118496 1189040 1965261 1dfccd vmlinux.4.4 > 633563118528 1189448 1941539 1da023 vmlinux.4.6 > 633277118496 1189592 1941365 1d9f75 vmlinux.4.7 > 632299121120 1192784 1946203 1db25b vmlinux.4.9 I would certainly hope that GCC's -Os gets better over time. However, I find the increase in data/bss and thus overall size in 4.9 concerning. Any idea what that comes from? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall
On Fri, Jan 23, 2015 at 02:46:10PM -0500, Theodore Ts'o wrote: > On Fri, Jan 23, 2015 at 12:37:16PM -0600, Tom Zanussi wrote: > > Many embedded systems have no use for getrandom, and could benefit > > from the size savings gained by omitting it. Add a new EXPERT config > > option, CONFIG_GETRANDOM_SYSCALL (default y), to support compiling it > > out. > > I'm really not sure this is a good idea. Even the tiniest embedded > device need secure crypto. [...] > We know already that home routers are running ancient kernels that are > absolutely no protection whatever. Is saving a few bytes really worth > potentially opening up a similar attack vector on devices that will > probably be at least an order of magnitude or more numerous than home > routers, and even harder to upgrade once they get out there? > > And if you don't have a good random number generator, you really are > *toast*. > > It's for this reason that /dev/[u]random were not eligible from being > disabled from the very beginning; it's too much of an attractive > nuisance to a clueless product manager Forcing the availability of the random devices and getrandom syscall will not force userspace to actually *use* them, and there do exist real devices that do not need them. We're not yet talking about the full in-kernel entropy infrastructure, which should also be removable *if* you aren't using it for CONFIG_NET or similar. We're talking about the userspace interfaces. If you aren't running any userspace bits that open /dev/*random or that call getrandom, forcing the existence of those devices will not magically make the system more secure. Not all userspaces actually need randomness, and some of those that do have better alternatives than /dev/*random or getrandom (such as hardware RNGs). - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] epoll: Add epoll_pwait1 syscall
On Thu, Jan 08, 2015 at 09:57:24AM -0800, Andy Lutomirski wrote:
> On Thu, Jan 8, 2015 at 1:12 AM, Miklos Szeredi wrote:
> > On Thu, 2015-01-08 at 16:25 +0800, Fam Zheng wrote:
> >> Applications could use epoll interface when then need to poll a big number
> >> of
> >> files in their main loops, to achieve better performance than ppoll(2).
> >> Except
> >> for one concern: epoll only takes timeout parameters in microseconds,
> >> rather
> >> than nanoseconds.
> >>
> >> That is a drawback we should address. For a real case in QEMU, we run into
> >> a
> >> scalability issue with ppoll(2) when many devices are attached to guest, in
> >> which case many host fds, such as virtual disk images and sockets, need to
> >> be
> >> polled by the main loop. As a result we are looking at switching to epoll,
> >> but
> >> the coarse timeout precision is a trouble, as explained below.
> >>
> >> We're already using prctl(PR_SET_TIMERSLACK, 1) which is necessary to
> >> implement
> >> timers in the main loop; and we call ppoll(2) with the next firing timer as
> >> timeout, so when ppoll(2) returns, we know that we have more work to do
> >> (either
> >> handling IO events, or fire a timer callback). This is natual and
> >> efficient,
> >> except that ppoll(2) itself is slow.
> >>
> >> Now that we want to switch to epoll, to speed up the polling. However the
> >> timer
> >> slack setting will be effectively undone, because that way we will have to
> >> round up the timeout to microseconds honoring timer contract. But
> >> consequently,
> >> this hurts the general responsiveness.
> >>
> >> Note: there are two alternatives, without changing kernel:
> >>
> >> 1) Leading ppoll(2), with the epollfd only and a nanosecond timeout. It
> >> won't
> >> be slow as one fd is polled. No more scalability issue. And if there are
> >> events, we know from ppoll(2)'s return, then we do the epoll_wait(2) with
> >> timeout=0; otherwise, there can't be events for the epoll, skip the
> >> following
> >> epoll_wait and just continue with other work.
> >>
> >> 2) Setup and add a timerfd to epoll, then we do epoll_wait(...,
> >> timeout=-1).
> >> The timerfd will hopefully force epoll_wait to return when it timeouts,
> >> even if
> >> no other events have arrived. This will inheritly give us timerfd's
> >> precision.
> >> Note that for each poll, the desired timeout is different because the next
> >> timer is different, so that, before each epoll_wait(2), there will be a
> >> timerfd_settime syscall to set it to a proper value.
> >>
> >> Unfortunately, both approaches require one more syscall per iteration,
> >> compared
> >> to the original single ppoll(2), cost of which is unneglectable when we
> >> talk
> >> about nanosecond granularity.
>
> I'd like to see a more ambitious change, since the timer isn't the
> only problem like this. Specifically, I'd like a syscall that does a
> list of epoll-related things and then waits. The list of things could
> include, at least:
>
> - EPOLL_CTL_MOD actions: level-triggered epoll users are likely to
> want to turn on and off their requests for events on a somewhat
> regular basis.
>
> - timerfd_settime actions: this allows a single syscall to wait and
> adjust *both* monotonic and real-time wakeups.
>
> Would this make sense? It could look like:
>
> int epoll_mod_and_pwait(int epfd,
> struct epoll_event *events, int maxevents,
> struct epoll_command *commands, int ncommands,
> const sigset_t *sigmask);
That's a complicated syscall. (And it also doesn't have room for the
flags argument.)
At that point, why not just have a syscall like this:
struct syscall {
unsigned long num;
unsigned long params[6];
};
int sys_many(size_t count, struct syscall *syscalls, int *results, unsigned
long flags);
I think that has been discussed in the past.
Or, these days, that might be better done via eBPF, which would avoid
the need for flags like "return on error"; an eBPF program could decide
how to proceed after each call.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
On Wed, Jan 28, 2015 at 10:07:51PM +0100, Pavel Machek wrote: > On Fri 2015-01-23 12:37:11, Tom Zanussi wrote: > > Some embedded systems with tightly controlled userspace have no use > > for /dev/zero, and could benefit from the size savings gained by > > omitting it. Add a new EMBEDDED config option to disable it. > > > > bloat-o-meter (based on tinyconfig): > > > > add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-391 (-391) > > function old new delta > > chr_dev_init 162 147 -15 > > mmap_zero 16 - -16 > > zero_fops116 --116 > > zero_bdi 244 --244 > > > > Signed-off-by: Tom Zanussi > > I'm not sure that 400 bytes are worth additional Kconfig noise. .. and > pretty much everyone needs /dev/zero... Relatively few, actually, given MMAP_ANONYMOUS. Memory isn't allocated via an mmap of /dev/zero. It's useful for systems with shells that want to redirect from it or read from it, but less useful for environments with entirely compiled code. /dev/null is much more commonly needed, though there are still systems that won't need it (and can just disable read/writes on an fd entirely rather than duping /dev/null to that fd). That said, I'd be entirely in favor of consolidating many of these "miscellaneous character device" options into a couple of Kconfig options. It doesn't seem critical to *individually* control each of these files in /dev. Personally, I'm hoping that we eventually end up with a disableable CONFIG_CHAR similar to CONFIG_BLOCK. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/7] clone4: Add a CLONE_AUTOREAP flag to automatically reap the child process
On Fri, Mar 20, 2015 at 08:09:14PM +0100, Oleg Nesterov wrote: > On 03/20, Thiago Macieira wrote: > > > > On Friday 20 March 2015 19:14:04 Oleg Nesterov wrote: > > > Also. I forgot that the kernel always resets ->exit_signal to SIGCHLD on > > > exec or reparenting. Reparenting is probably fine. But what about exec? > > > Should it keep ->exit_signal == 0 if "autoreap" ? I think it should not, > > > to > > > avoid the strange special case. > > > > Not delivering any signal was the objective of this patch series, so yes > > exit_signal == 0 should survive an exec and even re-exec. > > OK, but then perhaps we should never send SIGCHLD (on exit) if "autoreap", > to make the logic simple. > > And copy_process() should probably do > > if ((clone_flags & CSIGNAL) && (clone_flags && CLONE_AUTOREAP)) > return -EINVAL; > > so that we still can change this behaviour later. I'm fine with that, as it would handle the particular use case we care about. However, the reset-signal-on-reparent thing might still make sense, particularly for the ptrace-reparent case (less so for the reparent-to-child-reaper case). - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/7] CLONE_FD: Task exit notification via file descriptor
On Tue, Mar 31, 2015 at 10:08:07PM +0200, Jonathan Corbet wrote:
> So I finally got around to having a look at this, and one thing caught my
> eye:
>
> > read(2) (and similar)
> > When the new process exits, reading from the
> > file
> > descriptor produces a single clonefd_info structure:
> >
> > struct clonefd_info {
> > uint32_t code; /* Signal code */
> > uint32_t status; /* Exit status or signal */
> > uint64_t utime; /* User CPU time */
> > uint64_t stime; /* System CPU time */
> > };
>
> This would appear to assume that a clonefd_info structure is the only
> thing that will ever be read from this descriptor. It seems to me that
> there is the potential for, someday, wanting to be able to read and write
> other things as well. Should this structure be marked with type and
> length fields so that other structures could be added in the future?
I don't think it makes sense for a caller to get an arbitrary structure
on read(), and have to figure out what they got and ignore something
they don't understand. Instead, I think it makes more sense for the
caller to say "Hey, here's a flag saying I understand the new thing, go
ahead and give me the new thing". So, for instance, if you want to
receive SIGSTOP/SIGCONT messages for child processes through this
descriptor, we could add a flag for that.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rcu: introduce list_last_or_null_rcu
On Thu, May 28, 2015 at 04:35:27PM -0400, Dan Streetman wrote:
> Add list_last_or_null_rcu(), to simplify getting the last entry from a
> rcu-protected list. The standard list_last_entry() can't be used as it
> is not rcu-protected; the list may be modified concurrently. And the
> ->prev pointer can't be used, as only the ->next pointers are protected
> by rcu.
>
> This simply iterates forward through the entire list, to get to the last
> entry. If the list is empty, it returns NULL.
>
> Signed-off-by: Dan Streetman
The list iteration functions are macros because they introduce a loop
with attached loop block. For this, is there any reason not to make it
an inline function instead of a macro?
> include/linux/rculist.h | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> index a18b16f..954fde5 100644
> --- a/include/linux/rculist.h
> +++ b/include/linux/rculist.h
> @@ -293,6 +293,27 @@ static inline void list_splice_init_rcu(struct list_head
> *list,
> })
>
> /**
> + * list_last_or_null_rcu - get the last element from a list
> + * @ptr:the list head to take the element from.
> + * @type: the type of the struct this is embedded in.
> + * @member: the name of the list_head within the struct.
> + *
> + * Note that if the list is empty, it returns NULL.
> + *
> + * This primitive may safely run concurrently with the _rcu list-mutation
> + * primitives such as list_add_rcu() as long as it's guarded by
> rcu_read_lock().
> + */
> +#define list_last_or_null_rcu(ptr, type, member) \
> +({ \
> + struct list_head *__ptr = (ptr); \
> + struct list_head *__last = __ptr; \
> + struct list_head *__entry = list_next_rcu(__ptr); \
> + for (; __entry != __ptr; __entry = list_next_rcu(__entry)) \
> + __last = __entry; \
> + likely(__ptr != __last) ? list_entry_rcu(__last, type, member) : NULL; \
> +})
> +
> +/**
> * list_for_each_entry_rcu - iterate over rcu list of given type
> * @pos: the type * to use as a loop cursor.
> * @head:the head for your list.
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rcu: introduce list_last_or_null_rcu
On Thu, May 28, 2015 at 04:44:59PM -0400, Dan Streetman wrote: > On Thu, May 28, 2015 at 4:42 PM, Dan Streetman wrote: > > On Thu, May 28, 2015 at 4:39 PM, wrote: > >> On Thu, May 28, 2015 at 04:35:27PM -0400, Dan Streetman wrote: > >>> Add list_last_or_null_rcu(), to simplify getting the last entry from a > >>> rcu-protected list. The standard list_last_entry() can't be used as it > >>> is not rcu-protected; the list may be modified concurrently. And the > >>> ->prev pointer can't be used, as only the ->next pointers are protected > >>> by rcu. > >>> > >>> This simply iterates forward through the entire list, to get to the last > >>> entry. If the list is empty, it returns NULL. > >>> > >>> Signed-off-by: Dan Streetman > >> > >> The list iteration functions are macros because they introduce a loop > >> with attached loop block. For this, is there any reason not to make it > >> an inline function instead of a macro? > > > > true, there's no reason i can see not to make it inline, let me send > > an updated patch. > > ha, as soon as i sent that email, i realized it can't be an inline > function, because the return value is (type *), not a predefined > value. Of course it could return void*, but unless there's a benefit > of making it an inline function, it seems to me like it would be > better as a #define. Fair enough. Sigh, C. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inherit TAINT_PROPRIETARY_MODULE v2
Christoph Hellwig wrote: > we've had a bug in our resolution of _GPL modules since day one, that > is a module can claim to be GPL licensed and use _GPL exports, while > it also depends on symbols from non-GPL modules. This is used as a > circumvention of the _GPL exports by using a small shim module using > the _GPL exports and the other functionality. This looks great. You might also consider doing the reverse: if a module imports any EXPORT_SYMBOL_GPL symbols, any symbols that module in turn exports shouldn't be importable by any module that doesn't explicitly claim to be GPL-compatible. Effectively, if a module imports any EXPORT_SYMBOL_GPL symbols, all of its exported symbols would then be treated as EXPORT_SYMBOL_GPL. This would catch the case of attempting to "wrap" EXPORT_SYMBOL_GPL symbols in the other direction, by re-exporting the same or similar functions to another module. (This would help catch mistakes, not just intentional malice.) - Josh Triplett
Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote: > The majority of the code in the kernel deals with hardware that was made > a long time ago, and we are regularly discussing which of those bits are > still needed. In some cases (e.g. 20+ year old RISC workstation support), > there are hobbyists that take care of maintainership despite there being > no commercial interest. In other cases (e.g. x.25 networking) it turned > out that there are very long-lived products that are actively supported > on new kernels. > > When I removed support for eight instruction set architectures in 2018, > those were the ones that no longer had any users of mainline kernels, > and removing them allowed later cleanup of cross-architecture code that > would have been much harder before. > > I propose adding a Documentation file that keeps track of any notable > kernel feature that could be classified as "obsolete", and listing > e.g. following properties: > > * Kconfig symbol controlling the feature > > * How long we expect to keep it as a minimum > > * Known use cases, or other reasons this needs to stay > > * Latest kernel in which it was known to have worked > > * Contact information for known users (mailing list, personal email) > > * Other features that may depend on this > > * Possible benefits of eventually removing it We had this once, in the form of feature-removal-schedule.txt. It was, itself, removed in commit 9c0ece069b32e8e122aea71aa47181c10eb85ba7. I *do* think there'd be value in having policies and processes for "how do we carefully remove a driver/architecture/etc we think nobody cares about". That's separate from having an actual in-kernel list of "things we think we can remove".
Re: [PATCH] checkpatch.pl: Add warning for new __packed additions
On Mon, Feb 24, 2014 at 03:38:16PM -0500, Tom Rini wrote:
> While there are valid reasons to use __packed, often the answer is that
> you should be doing something else here instead.
>
> Cc: Andrew Morton
> Cc: Joe Perches
> Cc: Josh Triplett
> Signed-off-by: Tom Rini
> ---
> scripts/checkpatch.pl |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 0ea2a1e..fef3b13 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -4010,6 +4010,11 @@ sub process {
> WARN("PREFER_PACKED",
>"__packed is preferred over
> __attribute__((packed))\n" . $herecurr);
> }
> +# Check for new packed usage, warn to use care
> + if ($line =~
> /\b(__attribute__\s*\(\s*\(.*\bpacked|__packed)\b/) {
> + WARN("NEW_PACKED",
> + "Adding new packed members is to be done with
> care\n" . $herecurr);
> + }
This seems wrong; "is to be done with care" is the very definition of a
false positive. At *best* this should always be CHK, and even then it
seems excessive.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] drivers: cpufreq: Mark function as static in cpufreq.c
On Wed, Feb 26, 2014 at 10:56:45PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, February 26, 2014 10:12:42 PM Rashika Kheria wrote:
> > Mark function as static in cpufreq.c because it is not
> > used outside this file.
> >
> > This eliminates the following warning in cpufreq.c:
> > drivers/cpufreq/cpufreq.c:355:9: warning: no previous prototype for
> > ‘show_boost’ [-Wmissing-prototypes]
> >
> > Signed-off-by: Rashika Kheria
>
> v2 has been Reviewed-by: Josh already, right?
Feel free to forward-propagate to v3 as well, if that helps.
> > ---
> > Changes since v1:
> > Incorrect Fix
> > Changes since v2:
> > Show Changelog
> >
> > drivers/cpufreq/cpufreq.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 08ca8c9..54fd670 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -352,7 +352,7 @@ EXPORT_SYMBOL_GPL(cpufreq_notify_post_transition);
> > /*
> > * SYSFS INTERFACE *
> > */
> > -ssize_t show_boost(struct kobject *kobj,
> > +static ssize_t show_boost(struct kobject *kobj,
> > struct attribute *attr, char *buf)
> > {
> > return sprintf(buf, "%d\n", cpufreq_driver->boost_enabled);
> >
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OPW kernel] [PATCH] checkpatch: Make "return is not a function" test quieter
On Thu, Feb 27, 2014 at 11:27:10AM -0800, Joe Perches wrote:
> This test is a bit noisy and opinions seem to agree that
> it should not warn in a lot more situations.
>
> It seems people agree that:
>
> return (foo || bar);
> and
> return foo || bar;
>
> are both acceptable style and checkpatch should be silent
> about them.
>
> For now, it warns on parentheses around a simple constant
> or a single function or a ternary.
>
> return (foo);
> return (foo(bar));
> return (foo ? bar : baz);
>
> The last ternary test may be quieted in the future.
>
> Modify the deparenthesize function to only strip balanced
> leading and trailing parentheses.
>
> Signed-off-by: Joe Perches
I'd suggest dropping the warning for parenthesized ternaries as well,
but in any case:
Reviewed-by: Josh Triplett
> scripts/checkpatch.pl | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 91308be..be4be81 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -439,9 +439,14 @@ our $FuncArg = qr{$Typecast{0,1}($LvalOrFunc|$Constant)};
> sub deparenthesize {
> my ($string) = @_;
> return "" if (!defined($string));
> - $string =~ s@^\s*\(\s*@@g;
> - $string =~ s@\s*\)\s*$@@g;
> +
> + while ($string =~ /^\s*\(.*\)\s*$/) {
> + $string =~ s@^\s*\(\s*@@;
> + $string =~ s@\s*\)\s*$@@;
> + }
> +
> $string =~ s@\s+@ @g;
> +
> return $string;
> }
>
> @@ -3362,14 +3367,17 @@ sub process {
> }
> }
>
> -# Return is not a function.
> +# return is not a function
> if (defined($stat) && $stat =~ /^.\s*return(\s*)\(/s) {
> my $spacing = $1;
> if ($^V && $^V ge 5.10.0 &&
> - $stat =~ /^.\s*return\s*$balanced_parens\s*;\s*$/) {
> - ERROR("RETURN_PARENTHESES",
> - "return is not a function, parentheses
> are not required\n" . $herecurr);
> -
> + $stat =~
> /^.\s*return\s*($balanced_parens)\s*;\s*$/) {
> + my $value = $1;
> + $value = deparenthesize($value);
> + if ($value =~ m/^\s*$FuncArg\s*(?:\?|$)/) {
> + ERROR("RETURN_PARENTHESES",
> + "return is not a function,
> parentheses are not required\n" . $herecurr);
> + }
> } elsif ($spacing !~ /\s+/) {
> ERROR("SPACING",
> "space required before the open
> parenthesis '('\n" . $herecurr);
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "opw-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opw-kernel+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 25/46] kernel: Add prototype declaration to header file include/linux/ftrace.h
On Thu, Feb 27, 2014 at 02:37:53PM -0500, Steven Rostedt wrote:
> On Thu, 27 Feb 2014 17:32:47 +0530
> Rashika Kheria wrote:
>
> > Add prototype declaration of function to header file
> > include/linux/ftrace.h because it is used by more than one file.
> >
> > This eliminates the following warning in kernel/trace/ftrace.c:
> > kernel/trace/ftrace.c:4914:5: warning: no previous prototype for
> > ‘ftrace_graph_entry_stub’ [-Wmissing-prototypes]
> >
> > Signed-off-by: Rashika Kheria
> > Reviewed-by: Josh Triplett
> > ---
> > include/linux/ftrace.h |2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> > index 68ea184..da1c31f 100644
> > --- a/include/linux/ftrace.h
> > +++ b/include/linux/ftrace.h
> > @@ -672,6 +672,8 @@ struct ftrace_graph_ret {
> > typedef void (*trace_func_graph_ret_t)(struct ftrace_graph_ret *); /*
> > return */
> > typedef int (*trace_func_graph_ent_t)(struct ftrace_graph_ent *); /* entry
> > */
> >
> > +int ftrace_graph_entry_stub(struct ftrace_graph_ent *trace);
>
> This doesn't need to be in a header file as it is only called by
> assmebly. But I have no problems with it being in one, but it should
> have a comment stating this:
>
> /* This is only called by assembly code, declared here for consistency */
That seems quite reasonable, yeah.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/46] kernel: MOve prototype declaration to header file include/linux/perf_event.h
On Thu, Feb 27, 2014 at 08:23:35PM +0100, Peter Zijlstra wrote: > On Thu, Feb 27, 2014 at 07:51:50AM -0800, Josh Triplett wrote: > > On Thu, Feb 27, 2014 at 12:54:14PM +0100, Peter Zijlstra wrote: > > > On Thu, Feb 27, 2014 at 05:02:48PM +0530, Rashika Kheria wrote: > > > > Add prototype declaration of function to header file > > > > include/linux/perf_event.h because it is used by more than one file. > > > > > > > > This eliminates the following warning in kernel/events/core.c: > > > > kernel/events/core.c:3743:13: warning: no previous prototype for > > > > ‘arch_perf_update_userpage’ [-Wmissing-prototypes] > > > > > > # git grep arch_perf_update_userpage > > > arch/x86/kernel/cpu/perf_event.c:void arch_perf_update_userpage(struct > > > perf_event_mmap_page *userpg, u64 now) > > > kernel/events/core.c:void __weak arch_perf_update_userpage(struct > > > perf_event_mmap_page *userpg, u64 now) > > > kernel/events/core.c: arch_perf_update_userpage(userpg, now); > > > > > > > > > There's two definitions; one weak, and one usage site. > > > > > > What gives? > > > > There's no prototype for the function anywhere, so -Wmissing-prototypes > > rightfully complains. Adding the prototype to a header included in both > > source files ensures that the function signatures must match, and > > eliminates the warning. > > Definitions don't require prior declarations. Only usage without prior > definitions require them. > > I still don't see a problem. There's value in -Wmissing-prototypes; it's equivalent to the Sparse check that ensures functions are marked as static when they're not used outside the file they're defined in (though unlike the Sparse check it only applies to functions, not data). The goal isn't "make the warning go away"; the goal of passing -Wmissing-prototypes is: - Get rid of unused functions (many of which have been caught by this effort). - Mark functions as static where possible (which enables the above and also improves code generation). - Include headers that declare functions in the source files that define them, not just in the source files that use them. That keeps the declaration and definition in sync (which has caught some real bugs as part of this effort). - When no such header exists for a function used across multiple files, add the prototype to an appropriate header and use that. Again, this has caught real bugs as part of this effort, when the definition and use were out of sync. (For instance, disagreeing in return type.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/46] kernel: Mark functions as static in sched/fair.c
On Thu, Feb 27, 2014 at 08:24:35PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 27, 2014 at 08:03:22AM -0800, Josh Triplett wrote:
> > Did you perhaps check, and notice that there are *zero* uses of this
> > function in the kernel? Nothing overrides this weak symbol; it is no
> > longer needed. You removed the one and only user in your commit:
>
> I know that; but you don't get to remove interfaces under the guise of a
> static checker and without mention of such in the changelog.
So the changelog message needed improvement. Got it; that would have
been helpful to hear.
The kernel hardly goes to great lengths to preserve old interfaces with
no users (per stable_api_nonsense), and the commit message already stated
that the function was being marked as static because it wasn't used
elsewhere. But sure, perhaps something like the following, added to the
commit message, would address your concern?
"""
arch_scale_smt_power, in particular, is a __weak function provided for
architectures to override. However, the only overriding definition was
removed before v3.6, in commit ee08d1284ea9235b29bd2d9b7493b4b4cf3da09c
("sched/x86: Remove broken power estimation"). Thus, drop the __weak
and make the function static.
"""
Or would you prefer to see it completely eliminated (inlining it into
its caller) as part of the same patch?
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 17/55] rcutorture: Abstract torture_param()
On Tue, Feb 18, 2014 at 01:31:47PM -0800, Paul E. McKenney wrote: > On Mon, Feb 17, 2014 at 04:23:01PM -0800, Josh Triplett wrote: > > On Mon, Feb 17, 2014 at 02:12:21PM -0800, Paul E. McKenney wrote: > > > From: "Paul E. McKenney" > > > > > > Create a torture_param() macro and apply it to rcutorture in order to > > > save a few lines of code. This same macro may be applied to other > > > torture frameworks. > > > > > > Signed-off-by: Paul E. McKenney > > > > Your commit message says "torture_param", but your code says > > "torture_parm". Let's go with the former, please; no need to creat more > > disemvoweled abbreviations. > > Gd pnt, fxd s sggstd. Thnks! > > Also, this seems rather generally useful. A quick check with "git grep > > -B2 MODULE_PARM_DESC" turns up numerous instances of the pattern. You > > might consider adding this as a helper DECLARE_MODULE_PARAM_RO in > > include/linux/moduleparam.h (possibly calling a generalized version that > > takes the mode as another parameter). > > Added to the todo list. Another parameter is static vs. not -- I only > had one non-static instance, which I left open-coded. I debated that one. You could leave out the "static" and just write "static DECLARE_MODULE_PARAM_RO", but given that you almost always *want* static for a module parameter... - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 37/55] rcutorture: Abstract torture_create_kthread()
On Tue, Feb 18, 2014 at 01:36:11PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 17, 2014 at 04:34:02PM -0800, Josh Triplett wrote:
> > On Mon, Feb 17, 2014 at 02:12:41PM -0800, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney"
> > >
> > > Creation of kthreads is not RCU-specific, so this commit abstracts
> > > out torture_create_kthread(), saving a few tens of lines of code in
> > > the process.
> > >
> > > Signed-off-by: Paul E. McKenney
> >
> > One comment below.
> >
> > > include/linux/torture.h | 8 +++-
> > > kernel/rcu/rcutorture.c | 98
> > > ++---
> > > kernel/torture.c| 80 +---
> > > 3 files changed, 60 insertions(+), 126 deletions(-)
> > >
> > > diff --git a/include/linux/torture.h b/include/linux/torture.h
> > > index db9bc7756a32..e5264c6ecfeb 100644
> > > --- a/include/linux/torture.h
> > > +++ b/include/linux/torture.h
> > > @@ -47,7 +47,7 @@
> > > #define VERBOSE_TOROUT_STRING(s) \
> > > do { if (verbose) pr_alert("%s" TORTURE_FLAG " %s\n", torture_type, s);
> > > } while (0)
> > > #define VERBOSE_TOROUT_ERRSTRING(s) \
> > > - do { if (verbose) pr_alert("%s" TORTURE_FLAG "!!! " s "\n",
> > > torture_type); } while (0)
> > > + do { if (verbose) pr_alert("%s" TORTURE_FLAG "!!! %s\n", torture_type,
> > > s); } while (0)
> >
> > This change is also unrelated, and should not occur in this commit.
>
> It is required for the invocation in _torture_create_kthread() below.
> I have updated the commit log to call this out.
I suppose it just seemed like both of these changes could occur in a
separate commit enhancing the output macros, which would come before the
commit using them. But OK.
Reviewed-by: Josh Triplett
> Thanx, Paul
>
> > - Josh Triplett
> >
> > > /* Definitions for a non-string torture-test module parameter. */
> > > #define torture_parm(type, name, init, msg) \
> > > @@ -89,5 +89,11 @@ bool torture_cleanup(void);
> > > bool torture_must_stop(void);
> > > bool torture_must_stop_irq(void);
> > > void torture_kthread_stopping(char *title);
> > > +int _torture_create_kthread(int (*fn)(void *arg), void *arg, char *s,
> > > char *m,
> > > + char *f, struct task_struct **tp);
> > > +
> > > +#define torture_create_kthread(n, arg, tp) \
> > > + _torture_create_kthread(n, (arg), #n, "Creating " #n " task", \
> > > + "Failed to create " #n, &(tp))
> > >
> > > #endif /* __LINUX_TORTURE_H */
> > > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> > > index cf365160b44f..951a5559d9fa 100644
> > > --- a/kernel/rcu/rcutorture.c
> > > +++ b/kernel/rcu/rcutorture.c
> > > @@ -1104,19 +1104,9 @@ static int rcu_torture_stall(void *args)
> > > /* Spawn CPU-stall kthread, if stall_cpu specified. */
> > > static int __init rcu_torture_stall_init(void)
> > > {
> > > - int ret;
> > > -
> > > if (stall_cpu <= 0)
> > > return 0;
> > > - VERBOSE_TOROUT_STRING("Creating rcu_torture_stall task");
> > > - stall_task = kthread_run(rcu_torture_stall, NULL, "rcu_torture_stall");
> > > - if (IS_ERR(stall_task)) {
> > > - ret = PTR_ERR(stall_task);
> > > - stall_task = NULL;
> > > - return ret;
> > > - }
> > > - torture_shuffle_task_register(stall_task);
> > > - return 0;
> > > + return torture_create_kthread(rcu_torture_stall, NULL, stall_task);
> > > }
> > >
> > > /* Clean up after the CPU-stall kthread, if one was spawned. */
> > > @@ -1225,29 +1215,13 @@ static int rcu_torture_barrier_init(void)
> > > return -ENOMEM;
> > > for (i = 0; i < n_barrier_cbs; i++) {
> > > init_waitqueue_head(&barrier_cbs_wq[i]);
> > > - VERBOSE_TOROUT_STRING("Creating rcu_torture_barrier_cbs task");
> > > - barrier_cbs_tasks[i] = kthread_run(rcu_torture_barrier_cbs,
> > > -(void *)(long)i,
> > > -"rcu_torture_barrier_cbs"
Re: [PATCH] efi-bgrt: Add error handling; inform the user when ignoring the BGRT
On Thu, Jul 31, 2014 at 11:31:10AM +0100, Matt Fleming wrote:
> On Wed, 30 Jul, at 12:23:32PM, Josh Triplett wrote:
> > @@ -61,14 +81,18 @@ void __init efi_bgrt_init(void)
> > early_iounmap(image, sizeof(bmp_header));
> > bgrt_image_size = bmp_header.size;
> >
> > - bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL);
> > - if (!bgrt_image)
> > + bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL | __GFP_NOWARN);
> > + if (!bgrt_image) {
> > + pr_err("Ignoring BGRT: failed to allocate memory for image
> > (wanted %zu bytes)\n",
> > + bgrt_image_size);
> > return;
>
> I'm not sure that using __GFP_NOWARN is the right thing to do here. If
> for some reason we can't handle the BGRT image we should include checks
> in the BGRT code, rather than relying on the page-allocation machinery
> to save us.
>
> Let's just use an explicit limit on the size of the BGRT image we're
> willing to handle.
I started to add an explicit limit, but any reasonable limit (large
enough for modern screens) would be large enough that there's still a
non-trivial possibility of allocation failure. And I think it makes
sense for BGRT image allocation to be non-fatal and minimally noisy
(just a single-line error, not a scary-looking allocation warning),
considering the highly optional and cosmetic nature of BGRT. So, I
believe __GFP_NOWARN makes sense.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 tip/core/rcu 0/10] RCU-tasks implementation
On Wed, Jul 30, 2014 at 05:39:14PM -0700, Paul E. McKenney wrote: > This series provides a prototype of an RCU-tasks implementation, which has > been requested to assist with tramopoline removal. This flavor of RCU > is task-based rather than CPU-based, and has voluntary context switch, > usermode execution, and the idle loops as its only quiescent states. > This selection of quiescent states ensures that at the end of a grace > period, there will no longer be any tasks depending on a trampoline that > was removed before the beginning of that grace period. This works because > such trampolines do not contain function calls, do not contain voluntary > context switches, do not switch to usermode, and do not switch to idle. I'm concerned about the amount of system overhead this introduces. Polling for holdout tasks seems quite excessive. If I understand the intended use case correctly, the users of this will want to free relatively small amounts of memory; thus, waiting a while to do so seems fine, especially if the system isn't under any particular memory pressure. Thus, rather than polling, could you simply flag the holdout tasks, telling the scheduler "hey, next time you don't have anything better to do..."? Then don't bother with them again unless the system runs low on memory and asks you to free some. (And mandate that you can only use this to free memory rather than for any other purpose.) Also, ideally this should remain entirely optional; nothing in the core kernel should depend on it. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 tip/core/rcu 0/10] RCU-tasks implementation
On Thu, Jul 31, 2014 at 06:30:12PM +0200, Peter Zijlstra wrote: > On Thu, Jul 31, 2014 at 09:19:02AM -0700, j...@joshtriplett.org wrote: > > Also, ideally this should remain entirely optional; nothing in the core > > kernel should depend on it. > > I suspect Steve wants it for ftrace :-) Which can be compiled out. :) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 tip/core/rcu 04/10] rcu: Export RCU-tasks APIs to GPL modules
On Wed, Jul 30, 2014 at 05:39:36PM -0700, Paul E. McKenney wrote: > From: Steven Rostedt > > This commit exports the RCU-tasks APIs, call_rcu_tasks(), > synchronize_rcu_tasks(), and rcu_barrier_tasks(), to GPL-licensed > kernel modules. > > Signed-off-by: Steven Rostedt > Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Should this remain a separate patch, or go into the patch that creates these APIs? > kernel/rcu/update.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c > index c8d304dc6d8a..1bfc07ed854e 100644 > --- a/kernel/rcu/update.c > +++ b/kernel/rcu/update.c > @@ -429,6 +429,7 @@ void synchronize_rcu_tasks(void) > /* Wait for the grace period. */ > wait_rcu_gp(call_rcu_tasks); > } > +EXPORT_SYMBOL_GPL(synchronize_rcu_tasks); > > /** > * rcu_barrier_tasks - Wait for in-flight call_rcu_tasks() callbacks. > @@ -441,6 +442,7 @@ void rcu_barrier_tasks(void) > /* There is only one callback queue, so this is easy. ;-) */ > synchronize_rcu_tasks(); > } > +EXPORT_SYMBOL_GPL(rcu_barrier_tasks); > > /* RCU-tasks kthread that detects grace periods and invokes callbacks. */ > static int __noreturn rcu_tasks_kthread(void *arg) > -- > 1.8.1.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 tip/core/rcu 03/10] rcu: Add synchronous grace-period waiting for RCU-tasks
On Wed, Jul 30, 2014 at 05:39:35PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> It turns out to be easier to add the synchronous grace-period waiting
> functions to RCU-tasks than to work around their absense in rcutorture,
> so this commit adds them. The key point is that the existence of
> call_rcu_tasks() means that rcutorture needs an rcu_barrier_tasks().
>
> Signed-off-by: Paul E. McKenney
With rcu_barrier_tasks being a trivial wrapper, why not just let
rcutorture call synchronize_rcu_tasks directly?
> include/linux/rcupdate.h | 2 ++
> kernel/rcu/update.c | 55
>
> 2 files changed, 57 insertions(+)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 3299ff98ad03..17c7e25c38be 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -216,6 +216,8 @@ void synchronize_sched(void);
> * memory ordering guarantees.
> */
> void call_rcu_tasks(struct rcu_head *head, void (*func)(struct rcu_head
> *head));
> +void synchronize_rcu_tasks(void);
> +void rcu_barrier_tasks(void);
>
> #ifdef CONFIG_PREEMPT_RCU
>
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index b92268647a01..c8d304dc6d8a 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -387,6 +387,61 @@ void call_rcu_tasks(struct rcu_head *rhp, void
> (*func)(struct rcu_head *rhp))
> }
> EXPORT_SYMBOL_GPL(call_rcu_tasks);
>
> +/**
> + * synchronize_rcu_tasks - wait until an rcu-tasks grace period has elapsed.
> + *
> + * Control will return to the caller some time after a full rcu-tasks
> + * grace period has elapsed, in other words after all currently
> + * executing rcu-tasks read-side critical sections have elapsed. These
> + * read-side critical sections are delimited by calls to schedule(),
> + * cond_resched_rcu_qs(), idle execution, userspace execution, calls
> + * to synchronize_rcu_tasks(), and (in theory, anyway) cond_resched().
> + *
> + * This is a very specialized primitive, intended only for a few uses in
> + * tracing and other situations requiring manipulation of function
> + * preambles and profiling hooks. The synchronize_rcu_tasks() function
> + * is not (yet) intended for heavy use from multiple CPUs.
> + *
> + * Note that this guarantee implies further memory-ordering guarantees.
> + * On systems with more than one CPU, when synchronize_rcu_tasks() returns,
> + * each CPU is guaranteed to have executed a full memory barrier since the
> + * end of its last RCU-tasks read-side critical section whose beginning
> + * preceded the call to synchronize_rcu_tasks(). In addition, each CPU
> + * having an RCU-tasks read-side critical section that extends beyond
> + * the return from synchronize_rcu_tasks() is guaranteed to have executed
> + * a full memory barrier after the beginning of synchronize_rcu_tasks()
> + * and before the beginning of that RCU-tasks read-side critical section.
> + * Note that these guarantees include CPUs that are offline, idle, or
> + * executing in user mode, as well as CPUs that are executing in the kernel.
> + *
> + * Furthermore, if CPU A invoked synchronize_rcu_tasks(), which returned
> + * to its caller on CPU B, then both CPU A and CPU B are guaranteed
> + * to have executed a full memory barrier during the execution of
> + * synchronize_rcu_tasks() -- even if CPU A and CPU B are the same CPU
> + * (but again only if the system has more than one CPU).
> + */
> +void synchronize_rcu_tasks(void)
> +{
> + /* Complain if the scheduler has not started. */
> + rcu_lockdep_assert(!rcu_scheduler_active,
> +"synchronize_rcu_tasks called too soon");
> +
> + /* Wait for the grace period. */
> + wait_rcu_gp(call_rcu_tasks);
> +}
> +
> +/**
> + * rcu_barrier_tasks - Wait for in-flight call_rcu_tasks() callbacks.
> + *
> + * Although the current implementation is guaranteed to wait, it is not
> + * obligated to, for example, if there are no pending callbacks.
> + */
> +void rcu_barrier_tasks(void)
> +{
> + /* There is only one callback queue, so this is easy. ;-) */
> + synchronize_rcu_tasks();
> +}
> +
> /* RCU-tasks kthread that detects grace periods and invokes callbacks. */
> static int __noreturn rcu_tasks_kthread(void *arg)
> {
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 tip/core/rcu 05/10] rcutorture: Add torture tests for RCU-tasks
On Wed, Jul 30, 2014 at 05:39:37PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit adds torture tests for RCU-tasks. It also fixes a bug that
> would segfault for an RCU flavor lacking a callback-barrier function.
>
> Signed-off-by: Paul E. McKenney
Seems reasonable; however, you could also set .cb_barrier =
synchronize_rcu_tasks and drop rcu_barrier_tasks.
Either way:
Reviewed-by: Josh Triplett
> include/linux/rcupdate.h | 1 +
> kernel/rcu/rcutorture.c | 40 +++-
> 2 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 17c7e25c38be..ecb2198849e0 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -55,6 +55,7 @@ enum rcutorture_type {
> RCU_FLAVOR,
> RCU_BH_FLAVOR,
> RCU_SCHED_FLAVOR,
> + RCU_TASKS_FLAVOR,
> SRCU_FLAVOR,
> INVALID_RCU_FLAVOR
> };
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index febe07062ac5..6d12ab6675bc 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -602,6 +602,42 @@ static struct rcu_torture_ops sched_ops = {
> };
>
> /*
> + * Definitions for RCU-tasks torture testing.
> + */
> +
> +static int tasks_torture_read_lock(void)
> +{
> + return 0;
> +}
> +
> +static void tasks_torture_read_unlock(int idx)
> +{
> +}
> +
> +static void rcu_tasks_torture_deferred_free(struct rcu_torture *p)
> +{
> + call_rcu_tasks(&p->rtort_rcu, rcu_torture_cb);
> +}
> +
> +static struct rcu_torture_ops tasks_ops = {
> + .ttype = RCU_TASKS_FLAVOR,
> + .init = rcu_sync_torture_init,
> + .readlock = tasks_torture_read_lock,
> + .read_delay = rcu_read_delay, /* just reuse rcu's version. */
> + .readunlock = tasks_torture_read_unlock,
> + .completed = rcu_no_completed,
> + .deferred_free = rcu_tasks_torture_deferred_free,
> + .sync = synchronize_rcu_tasks,
> + .exp_sync = synchronize_rcu_tasks,
> + .call = call_rcu_tasks,
> + .cb_barrier = rcu_barrier_tasks,
> + .fqs= NULL,
> + .stats = NULL,
> + .irq_capable= 1,
> + .name = "tasks"
> +};
> +
> +/*
> * RCU torture priority-boost testing. Runs one real-time thread per
> * CPU for moderate bursts, repeatedly registering RCU callbacks and
> * spinning waiting for them to be invoked. If a given callback takes
> @@ -1295,7 +1331,8 @@ static int rcu_torture_barrier_cbs(void *arg)
> if (atomic_dec_and_test(&barrier_cbs_count))
> wake_up(&barrier_wq);
> } while (!torture_must_stop());
> - cur_ops->cb_barrier();
> + if (cur_ops->cb_barrier != NULL)
> + cur_ops->cb_barrier();
> destroy_rcu_head_on_stack(&rcu);
> torture_kthread_stopping("rcu_torture_barrier_cbs");
> return 0;
> @@ -1534,6 +1571,7 @@ rcu_torture_init(void)
> int firsterr = 0;
> static struct rcu_torture_ops *torture_ops[] = {
> &rcu_ops, &rcu_bh_ops, &rcu_busted_ops, &srcu_ops, &sched_ops,
> + &tasks_ops,
> };
>
> if (!torture_init_begin(torture_type, verbose, &rcutorture_runnable))
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 tip/core/rcu 0/10] RCU-tasks implementation
On Thu, Jul 31, 2014 at 09:58:43AM -0700, Paul E. McKenney wrote: > On Thu, Jul 31, 2014 at 09:19:02AM -0700, j...@joshtriplett.org wrote: > > On Wed, Jul 30, 2014 at 05:39:14PM -0700, Paul E. McKenney wrote: > > > This series provides a prototype of an RCU-tasks implementation, which has > > > been requested to assist with tramopoline removal. This flavor of RCU > > > is task-based rather than CPU-based, and has voluntary context switch, > > > usermode execution, and the idle loops as its only quiescent states. > > > This selection of quiescent states ensures that at the end of a grace > > > period, there will no longer be any tasks depending on a trampoline that > > > was removed before the beginning of that grace period. This works because > > > such trampolines do not contain function calls, do not contain voluntary > > > context switches, do not switch to usermode, and do not switch to idle. > > > > I'm concerned about the amount of system overhead this introduces. > > Polling for holdout tasks seems quite excessive. If I understand the > > intended use case correctly, the users of this will want to free > > relatively small amounts of memory; thus, waiting a while to do so seems > > fine, especially if the system isn't under any particular memory > > pressure. > > > > Thus, rather than polling, could you simply flag the holdout > > tasks, telling the scheduler "hey, next time you don't have anything > > better to do..."? Then don't bother with them again unless the system > > runs low on memory and asks you to free some. (And mandate that you can > > only use this to free memory rather than for any other purpose.) > > One of the many of my alternative suggestions that Steven rejected was > to simply leak the memory. ;-) > > But from what I can see, if we simply flag the holdout tasks, we > either are also holding onto the task_struct structures, re-introducing > concurrency to the list of holdout tasks, or requiring that the eventual > scan for holdout tasks scan the entire task list. Neither of these seems > particularly appetizing to me. > > The nice thing about Lai Jiangshan's suggestion is that it allows the > scan of the holdout list to be done completely unsynchronized, which > allows pauses during the scan, thus allowing the loop to check for > competing work on that CPU. This should get almost all the effect > of indefinite delay without the indefinite delay (at least in the > common case). > > Or am I missing something here? If you only allow a single outstanding set of callbacks at a time, you could have a single flag stored in the task, combined with a count stored with the set of callbacks. Each time one of the holdout tasks comes up, clear the flag and decrement the count. If and only if you get asked to free up memory, start poking the scheduler to bring up those tasks. When the count hits 0, free the memory. The set of trampolines won't change often, and presumably only changes in response to user-driven requests to trace or stop tracing things. So, if you have to wait for the existing set of callbacks to go away before adding more, that seems fine. And you could then ditch polling entirely. > > Also, ideally this should remain entirely optional; nothing in the core > > kernel should depend on it. > > Agreed, the CONFIG_TASKS_RCU is not likely to disappear anytime soon. > I therefore do not see RCU-tasks as an obstacle to kernel tinification. > I also would also guess that you might complain if someone does try to > use if from the tinified core of the Linux kernel. ;-) Yes. :) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 tip/core/rcu 0/10] RCU-tasks implementation
On Thu, Jul 31, 2014 at 11:38:16AM -0700, Paul E. McKenney wrote: > On Thu, Jul 31, 2014 at 10:20:24AM -0700, j...@joshtriplett.org wrote: > > On Thu, Jul 31, 2014 at 09:58:43AM -0700, Paul E. McKenney wrote: > > > On Thu, Jul 31, 2014 at 09:19:02AM -0700, j...@joshtriplett.org wrote: > > > > On Wed, Jul 30, 2014 at 05:39:14PM -0700, Paul E. McKenney wrote: > > > > > This series provides a prototype of an RCU-tasks implementation, > > > > > which has > > > > > been requested to assist with tramopoline removal. This flavor of RCU > > > > > is task-based rather than CPU-based, and has voluntary context switch, > > > > > usermode execution, and the idle loops as its only quiescent states. > > > > > This selection of quiescent states ensures that at the end of a grace > > > > > period, there will no longer be any tasks depending on a trampoline > > > > > that > > > > > was removed before the beginning of that grace period. This works > > > > > because > > > > > such trampolines do not contain function calls, do not contain > > > > > voluntary > > > > > context switches, do not switch to usermode, and do not switch to > > > > > idle. > > > > > > > > I'm concerned about the amount of system overhead this introduces. > > > > Polling for holdout tasks seems quite excessive. If I understand the > > > > intended use case correctly, the users of this will want to free > > > > relatively small amounts of memory; thus, waiting a while to do so seems > > > > fine, especially if the system isn't under any particular memory > > > > pressure. > > > > > > > > Thus, rather than polling, could you simply flag the holdout > > > > tasks, telling the scheduler "hey, next time you don't have anything > > > > better to do..."? Then don't bother with them again unless the system > > > > runs low on memory and asks you to free some. (And mandate that you can > > > > only use this to free memory rather than for any other purpose.) > > > > > > One of the many of my alternative suggestions that Steven rejected was > > > to simply leak the memory. ;-) > > > > > > But from what I can see, if we simply flag the holdout tasks, we > > > either are also holding onto the task_struct structures, re-introducing > > > concurrency to the list of holdout tasks, or requiring that the eventual > > > scan for holdout tasks scan the entire task list. Neither of these seems > > > particularly appetizing to me. > > > > > > The nice thing about Lai Jiangshan's suggestion is that it allows the > > > scan of the holdout list to be done completely unsynchronized, which > > > allows pauses during the scan, thus allowing the loop to check for > > > competing work on that CPU. This should get almost all the effect > > > of indefinite delay without the indefinite delay (at least in the > > > common case). > > > > > > Or am I missing something here? > > > > If you only allow a single outstanding set of callbacks at a time, you > > could have a single flag stored in the task, combined with a count > > stored with the set of callbacks. Each time one of the holdout tasks > > comes up, clear the flag and decrement the count. If and only if you > > get asked to free up memory, start poking the scheduler to bring up > > those tasks. When the count hits 0, free the memory. > > > > The set of trampolines won't change often, and presumably only changes > > in response to user-driven requests to trace or stop tracing things. > > So, if you have to wait for the existing set of callbacks to go away > > before adding more, that seems fine. And you could then ditch polling > > entirely. > > If I understand what you are suggesting, this requires hooks in the > scheduler. I used to have hooks in the scheduler, but I dropped them in > favor of polling the voluntary context-switch count in response to Peter > Zijlstra's concerns about adding overhead to the scheduler's fastpaths. > > Therefore, although the flags are sometimes cleared externally from the > scheduling-clock interrupt (for usermode execution), it is quite possible > that a given task might never have its flag cleared asynchronously. > > Another approach might be to poll more slowly or to make the polling > evict itself if it detects that this CPU has something else to do. > Would either or both of these help? As discussed at lunch today, another option would be to drop the thread and handle cleanup synchronously from the caller in the tracing code, or fire off a kthread *on request* to handle it asynchronously. That would avoid paying the startup and overhead on a system that has tracing in the kernel but never uses it, as will likely occur with distro kernels. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please add the tiny tree to linux-next
On Tue, Sep 23, 2014 at 08:34:42AM +1000, Stephen Rothwell wrote: > Hi Josh, > > On Mon, 22 Sep 2014 10:53:04 -0700 Josh Triplett > wrote: > > > > Can you please add the tiny tree, branch tiny/next of > > https://git.kernel.org/pub/scm/linux/kernel/git/josh/linux.git , to > > linux-next? > > > > I'll be using this tree to upstream various patches for Linux kernel > > tinification. I plan to use topic branches under tiny/* for separate > > topics, typically based on the previous -rc1, merging them into > > tiny/next; when the merge window opens, I'll submit a pull request for > > tiny/next and start merging new tiny/* topic branches into a > > tiny/next-next branch or similar that will become the new tiny/next > > after tiny/next gets merged. > > Added from today. I used git:// instead of https:// for the URL. > > I do not want code for release N in linux-next until after (N-1)-rc1 > has been released. So, rather than moving tiny/next-next to tiny/next as soon as tiny/next gets merged during the merge window, wait until the end of the merge window (and the release of -rc1) to do so? That makes sense, to avoid causing confusion and unnecessary conflicts during the merge window. The code in tiny/next right now is based on 3.17-rc1, and is intended for 3.18. I'll send a pull request for 3.18 as soon as the 3.18 merge window opens, and any patches I receive after that point will go into tiny/next-next. I'll wait to move tiny/next-next to tiny/next until 3.18-rc1 is released. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] rcu: Add sparse check for RCU_INIT_POINTER()
On Thu, Sep 25, 2014 at 02:03:34PM -0400, Pranith Kumar wrote:
> Add a sparse check when RCU_INIT_POINTER() is used to assign a non __rcu
> annotated pointer.
>
> Signed-off-by: Pranith Kumar
Have you checked if this introduces a significant number of new warnings
in the kernel?
If not:
Reviewed-by: Josh Triplett
> include/linux/rcupdate.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index a4a819f..a033d8b 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -1047,6 +1047,7 @@ static inline notrace void
> rcu_read_unlock_sched_notrace(void)
> */
> #define RCU_INIT_POINTER(p, v) \
> do { \
> + rcu_dereference_sparse(p, __rcu); \
> p = RCU_INITIALIZER(v); \
> } while (0)
>
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Support compiling out madvise and fadvise
On Thu, Sep 25, 2014 at 01:21:13PM -0400, Johannes Weiner wrote: > On Mon, Sep 22, 2014 at 09:11:16AM -0700, Josh Triplett wrote: > > @@ -3,7 +3,7 @@ > > # > > > > mmu-y := nommu.o > > -mmu-$(CONFIG_MMU) := fremap.o gup.o highmem.o madvise.o memory.o > > mincore.o \ > > +mmu-$(CONFIG_MMU) := fremap.o gup.o highmem.o memory.o mincore.o \ > >mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \ > >vmalloc.o pagewalk.o pgtable-generic.o > > > > @@ -11,7 +11,7 @@ ifdef CONFIG_CROSS_MEMORY_ATTACH > > mmu-$(CONFIG_MMU) += process_vm_access.o > > endif > > > > -obj-y := filemap.o mempool.o oom_kill.o fadvise.o \ > > +obj-y := filemap.o mempool.o oom_kill.o \ > >maccess.o page_alloc.o page-writeback.o \ > >readahead.o swap.o truncate.o vmscan.o shmem.o \ > >util.o mmzone.o vmstat.o backing-dev.o \ > > @@ -28,6 +28,9 @@ else > > obj-y += bootmem.o > > endif > > > > +ifdef CONFIG_MMU > > + obj-$(CONFIG_ADVISE_SYSCALLS) += fadvise.o madvise.o > > +endif > > That makes fadvise MMU-only, but I don't see why it should be. > > Was that intentional? No. Fixed in v2; will send out momentarily. Thanks! - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] mm: Support compiling out madvise and fadvise
Many embedded systems will not need these syscalls, and omitting them saves space. Add a new EXPERT config option CONFIG_ADVISE_SYSCALLS (default y) to support compiling them out. bloat-o-meter: add/remove: 0/3 grow/shrink: 0/0 up/down: 0/-2250 (-2250) function old new delta sys_fadvise64 57 - -57 sys_fadvise64_64 691 --691 sys_madvise 1502 - -1502 Signed-off-by: Josh Triplett --- v2: Don't make fadvise depend on CONFIG_MMU. init/Kconfig| 10 ++ kernel/sys_ni.c | 3 +++ mm/Makefile | 8 ++-- 3 files changed, 19 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index e84c642..782a65b 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1537,6 +1537,16 @@ config AIO by some high performance threaded applications. Disabling this option saves about 7k. +config ADVISE_SYSCALLS + bool "Enable madvise/fadvise syscalls" if EXPERT + default y + help + This option enables the madvise and fadvise syscalls, used by + applications to advise the kernel about their future memory or file + usage, improving performance. If building an embedded system where no + applications use these syscalls, you can disable this option to save + space. + config PCI_QUIRKS default y bool "Enable PCI quirk workarounds" if EXPERT diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c index 391d4dd..d4709d4 100644 --- a/kernel/sys_ni.c +++ b/kernel/sys_ni.c @@ -156,6 +156,9 @@ cond_syscall(sys_process_vm_writev); cond_syscall(compat_sys_process_vm_readv); cond_syscall(compat_sys_process_vm_writev); cond_syscall(sys_uselib); +cond_syscall(sys_fadvise64); +cond_syscall(sys_fadvise64_64); +cond_syscall(sys_madvise); /* arch-specific weak syscall entries */ cond_syscall(sys_pciconfig_read); diff --git a/mm/Makefile b/mm/Makefile index 632ae77..2ad574d 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -3,7 +3,7 @@ # mmu-y := nommu.o -mmu-$(CONFIG_MMU) := fremap.o gup.o highmem.o madvise.o memory.o mincore.o \ +mmu-$(CONFIG_MMU) := fremap.o gup.o highmem.o memory.o mincore.o \ mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \ vmalloc.o pagewalk.o pgtable-generic.o @@ -11,7 +11,7 @@ ifdef CONFIG_CROSS_MEMORY_ATTACH mmu-$(CONFIG_MMU) += process_vm_access.o endif -obj-y := filemap.o mempool.o oom_kill.o fadvise.o \ +obj-y := filemap.o mempool.o oom_kill.o \ maccess.o page_alloc.o page-writeback.o \ readahead.o swap.o truncate.o vmscan.o shmem.o \ util.o mmzone.o vmstat.o backing-dev.o \ @@ -28,6 +28,10 @@ else obj-y += bootmem.o endif +obj-$(CONFIG_ADVISE_SYSCALLS) += fadvise.o +ifdef CONFIG_MMU + obj-$(CONFIG_ADVISE_SYSCALLS) += madvise.o +endif obj-$(CONFIG_HAVE_MEMBLOCK) += memblock.o obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] Silence even more W=2 warnings
On Fri, Sep 26, 2014 at 07:37:19PM +, Rustad, Mark D wrote:
> Most of the others come from null-entry table initializations, i.e. {
> 0 }, which give missing field initializer warnings.
I'd suggest that such initializers should just be {}, not { 0 }, and we
should teach compilers to specifically *not* complain about empty
initializers even when otherwise complaining about missing fields.
Initializing a structure to 0 is completely sensible.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OPW kernel] checkpatch: Does anyone care that comments are freeform aligned?
On Wed, Sep 24, 2014 at 11:41:14AM -0700, Joe Perches wrote:
> On Wed, 2014-09-24 at 07:47 +0200, Julia Lawall wrote:
> > In the following patch extract, one line is indented with spaces rather
> > than tabs. Is it intentional that checkpatch doesn't complain about this,
> > I guess due to the line being a comment?
> []
> > struct bcm_hdr_suppression_contextinfo {
> > - UCHAR ucaHdrSuppressionInBuf[MAX_PHS_LENGTHS]; /* Intermediate buffer
> > to accumulate pkt Header for PHS */
> > - UCHAR ucaHdrSuppressionOutBuf[MAX_PHS_LENGTHS + PHSI_LEN]; /*
> > Intermediate buffer containing pkt Header after PHS */
> > +/* Intermediate buffer to accumulate pkt Header for PHS */
> > + UCHAR ucaHdrSuppressionInBuf[MAX_PHS_LENGTHS];
> > + /* Intermediate buffer containing pkt Header after PHS */
> > + UCHAR ucaHdrSuppressionOutBuf[MAX_PHS_LENGTHS + PHSI_LEN];
> > };
>
> checkpatch does not care when comments start in any
> particular position or ensure comments have tabs
> preceding them.
>
> Does anyone care?
This should have already been caught by other whitespace checks that
check for indentations of 8 or more spaces. Similarly, mixed tab/space
indentations would get caught by those same checks. I don't think
checkpatch needs to check those.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] jffs2: fix sparse warning: unexpected unlock
On Mon, Sep 22, 2014 at 11:12:50AM -0700, Brian Norris wrote: > + linux-sparse > > On Thu, Sep 18, 2014 at 08:46:16PM +0200, Fabian Frederick wrote: > > fs/jffs2/summary.c:846:5: warning: context imbalance in > > 'jffs2_sum_write_sumnode' - unexpected unlock > > > > Signed-off-by: Fabian Frederick > > --- > > fs/jffs2/summary.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/fs/jffs2/summary.c b/fs/jffs2/summary.c > > index c522d09..a0bac7b 100644 > > --- a/fs/jffs2/summary.c > > +++ b/fs/jffs2/summary.c > > @@ -844,6 +844,8 @@ static int jffs2_sum_write_data(struct jffs2_sb_info > > *c, struct jffs2_eraseblock > > /* Write out summary information - called from jffs2_do_reserve_space */ > > > > int jffs2_sum_write_sumnode(struct jffs2_sb_info *c) > > + __releases(&c->erase_completion_lock) > > + __acquires(&c->erase_completion_lock) > > I'm not too familiar with sparse notations, but Documentation/sparse.txt > suggests the above is wrong, and the following is more accurate: > > __must_hold(&c->erase_completion_lock) > > But it looks like there are several other examples which do this. > Anyway, here's the relevant doc text, in case someone wants to clarify > it for me, or else tell me the documentation is wrong: > > __must_hold - The specified lock is held on function entry and exit. > > __acquires - The specified lock is held on function exit, but not entry. > > __releases - The specified lock is held on function entry, but not exit. > > So __acquires and __releases look mutually exclusive, but it's not clear > if __must_hold will actually cover what we want. (I haven't tested it.) __must_hold is indeed the correct annotation. (There isn't currently anything enforcing that, though.) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] Move BTRFS RCU string to common library
On Fri, Sep 19, 2014 at 02:01:30AM -0700, Omar Sandoval wrote: > The RCU-friendy string API used internally by BTRFS is generic enough for > common use. This doesn't add any new functionality, but instead just moves the > code and documents the existing API. > > Signed-off-by: Omar Sandoval One nit: shouldn't the returned rcu_string pointer have an __rcu address space annotation? With that fixed: Reviewed-by: Josh Triplett > fs/btrfs/check-integrity.c | 6 +-- > fs/btrfs/dev-replace.c | 19 +- > fs/btrfs/disk-io.c | 6 +-- > fs/btrfs/extent_io.c | 4 +- > fs/btrfs/ioctl.c | 4 +- > fs/btrfs/raid56.c | 2 +- > fs/btrfs/rcu-string.h | 56 > fs/btrfs/scrub.c | 15 > fs/btrfs/super.c | 2 +- > fs/btrfs/volumes.c | 14 +++ > include/linux/rcustring.h | 91 > ++ > 11 files changed, 128 insertions(+), 91 deletions(-) > delete mode 100644 fs/btrfs/rcu-string.h > create mode 100644 include/linux/rcustring.h > > diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c > index ce92ae3..4ccd7da 100644 > --- a/fs/btrfs/check-integrity.c > +++ b/fs/btrfs/check-integrity.c > @@ -94,6 +94,7 @@ > #include > #include > #include > +#include > #include "ctree.h" > #include "disk-io.h" > #include "hash.h" > @@ -103,7 +104,6 @@ > #include "print-tree.h" > #include "locking.h" > #include "check-integrity.h" > -#include "rcu-string.h" > > #define BTRFSIC_BLOCK_HASHTABLE_SIZE 0x1 > #define BTRFSIC_BLOCK_LINK_HASHTABLE_SIZE 0x1 > @@ -851,8 +851,8 @@ static int btrfsic_process_superblock_dev_mirror( > printk_in_rcu(KERN_INFO "New initial S-block (bdev %p, > %s)" >" @%llu (%s/%llu/%d)\n", >superblock_bdev, > - rcu_str_deref(device->name), dev_bytenr, > - dev_state->name, dev_bytenr, > + rcu_string_dereference(device->name), > + dev_bytenr, dev_state->name, dev_bytenr, >superblock_mirror_num); > list_add(&superblock_tmp->all_blocks_node, >&state->all_blocks_list); > diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c > index eea26e1..87d10cc 100644 > --- a/fs/btrfs/dev-replace.c > +++ b/fs/btrfs/dev-replace.c > @@ -25,6 +25,7 @@ > #include > #include > #include > +#include > #include > #include "ctree.h" > #include "extent_map.h" > @@ -34,7 +35,6 @@ > #include "volumes.h" > #include "async-thread.h" > #include "check-integrity.h" > -#include "rcu-string.h" > #include "dev-replace.h" > #include "sysfs.h" > > @@ -376,9 +376,9 @@ int btrfs_dev_replace_start(struct btrfs_root *root, > printk_in_rcu(KERN_INFO > "BTRFS: dev_replace from %s (devid %llu) to %s started\n", > src_device->missing ? "" : > - rcu_str_deref(src_device->name), > + rcu_string_dereference(src_device->name), > src_device->devid, > - rcu_str_deref(tgt_device->name)); > + rcu_string_dereference(tgt_device->name)); > > tgt_device->total_bytes = src_device->total_bytes; > tgt_device->disk_total_bytes = src_device->disk_total_bytes; > @@ -528,9 +528,10 @@ static int btrfs_dev_replace_finishing(struct > btrfs_fs_info *fs_info, > printk_in_rcu(KERN_ERR > "BTRFS: btrfs_scrub_dev(%s, %llu, %s) failed > %d\n", > src_device->missing ? "" : > - rcu_str_deref(src_device->name), > + rcu_string_dereference(src_device->name), > src_device->devid, > - rcu_str_deref(tgt_device->name), scrub_ret); > + rcu_string_dereference(tgt_device->name), > + scrub_ret); > btrfs_dev_replace_unlock(dev_replace); > mutex_unlock(&root->fs_info->fs_devices->device_list_mutex); > mutex_unlock(&root->fs_info->chunk_mutex); > @@ -544,9 +5
Re: rfc: checkpatch logical line continuations (was IBM Akebono: Add support for a new PHY interface to the IBM emac driver)
On Fri, Mar 07, 2014 at 01:02:44PM -0800, Joe Perches wrote:
> On Fri, 2014-03-07 at 15:41 -0500, David Miller wrote:
> > From: Alistair Popple
> > Date: Thu, 6 Mar 2014 14:52:25 +1100
> >
> > > + out_be32(dev->reg, in_be32(dev->reg) | WKUP_ETH_RGMIIEN
> > > + | WKUP_ETH_TX_OE | WKUP_ETH_RX_IE);
> >
> > When an expression spans multiple lines, the lines should end with
> > operators rather than begin with them.
>
> That's not in CodingStyle currently.
It's also not even remotely consistent across existing kernel code, and
it isn't obvious that there's a general developer consensus on the
"right" way to write it.
> Right now, checkpatch emits a --strict only warning on "&&" or "||"
> at the beginning of line but that could be changed to any "$Operators"
>
> our $Arithmetic = qr{\+|-|\*|\/|%};
> our $Operators= qr{
> <=|>=|==|!=|
> =>|->|<<|>>|<|>|!|~|
> &&|\|\||,|\^|\+\+|--|&|\||$Arithmetic
> }x;
>
> The ones that likely have a too high false positive rates
> are the negation "!" and bitwise "~".
I don't think warning about operators at start of line seems like a good
idea at all. There are plenty of cases where putting the operator at
the start of the line will produce a better result. (I'd actually
suggest that in *most* cases.)
> Also, using perl, it's hard to distinguish between a
> logical "&" and the address-of "&" as well as the
> multiplication "*" and indirection "*" so maybe those
> should be excluded too.
>
> And I think it should only be added as a --strict test.
Agreed, if even that.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 32/45] torture: Better summary diagnostics for build failures
On Tue, May 13, 2014 at 12:25:54PM -0700, Paul E. McKenney wrote: > On Sat, May 10, 2014 at 12:34:12PM -0700, Josh Triplett wrote: > > On Fri, May 09, 2014 at 05:48:38PM -0700, Paul E. McKenney wrote: > > > On Wed, May 07, 2014 at 03:11:39PM -0700, j...@joshtriplett.org wrote: > > > > On Mon, Apr 28, 2014 at 05:25:20PM -0700, Paul E. McKenney wrote: > > > > > From: "Paul E. McKenney" > > > > > > > > > > The reaction of kvm-recheck.sh is obscure at best, and easy to miss > > > > > completely. This commit therefore prints "BUG: Build failed" in the > > > > > summary at the end of a run. > > > > > > > > This commit also changes a dozen other things about the output that this > > > > commit message does not document. :) > > > > > > Well, I don't know about a dozen, but I did upgrade the commit message to > > > read as follows: > > > > > > The reaction of kvm-recheck.sh is obscure at best, and easy to > > > miss completely. This commit therefore prints "BUG: Build failed" > > > in the summary at the end of a run. This commit also adds the > > > line of dashes in cases where performance info is not available, > > > and also avoids printing nonsense diagnostics in cases where > > > some of the normal test output is not available. > > > > What about the change to kvm-test-1-run.sh? > > Right you are! > > The reaction of kvm-recheck.sh is obscure at best, and easy to > miss completely. This commit therefore prints "BUG: Build failed" > in the summary at the end of a run. This commit also adds the > line of dashes in cases where performance info is not available, > and also avoids printing nonsense diagnostics in cases where > some of the normal test output is not available. In addition, > this commit saves off the .config file even when the build fails. Looks good, ship it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/char/mem.c: Add /dev/ioports, supporting 16-bit and 32-bit ports
On Tue, May 13, 2014 at 03:10:59PM -0700, H. Peter Anvin wrote:
> On 05/09/2014 03:38 PM, Josh Triplett wrote:
> > On Fri, May 09, 2014 at 02:20:45PM -0700, H. Peter Anvin wrote:
> >> On 05/09/2014 02:12 PM, Arnd Bergmann wrote:
> >>>
> >>>> However, if we're going to have these devices I'm wondering if having
> >>>> /dev/portw and /dev/portl (or something like that) might not make sense,
> >>>> rather than requiring a system call per transaction.
> >>>
> >>> Actually the behavior of /dev/port for >1 byte writes seems questionable
> >>> already: There are very few devices on which writing to consecutive
> >>> port numbers makes sense. Normally you just want to write a series
> >>> of bytes (or 16/32 bit words) into the same port number instead,
> >>> as the outsb()/outsw()/outsl() functions do.
> >>>
> >>
> >> Indeed. I missed the detail that it increments the port index; it is
> >> virtually guaranteed to be bogus.
> >
> > Exactly. It might make sense to have ioport8/ioport16/ioport32 devices
> > that accept arbitrary-length reads and writes (divisible by the size)
> > and do the equivalent of the string I/O instructions outs/ins, but for
> > the moment I'd like to add the single device that people always seem to
> > want and can't get from /dev/port. If someone's doing enough writes
> > that doing a syscall per in/out instruction seems like too much
> > overhead, they can write a real device driver or use ioperm/iopl.
>
> I really have a problem with the logic "our current interface is wrong,
> so let's introduce another wrong interface which solves a narrow use
> case". In some ways it would actually be *better* to use an ioctl
> interface on /dev/port in that case...
ioport{8,16,32} seems preferable to an ioctl on /dev/port, but in any
case, I'd be happy to adapt this patch to whatever interface seems
preferable. I just don't want to let the perfect be the enemy of the
good here; 16-bit and 32-bit port operations are currently completely
impossible via /dev/port, and I'm primarily interested in fixing that,
not necessarily in creating a completely generalized interface for doing
high-performance repeated I/O operations that ought to be in the kernel
anyway.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-discuss] Reminder for kernel summit nominations
On Fri, May 09, 2014 at 11:23:19AM -0400, Theodore Ts'o wrote: > Also, if you have time to double check the e-mail addresses that we > have, the Google Spreadsheet is here: > > http://goo.gl/FsVUFX > Peter P Waskiewicz Jr PJ left Intel and now works for SolidFire, so his @intel.com address won't work anymore. I don't know his preferred new address. (Hopefully he plans to switch to something company-independent now.) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] kbuild/lto changes for 3.15-rc1
On Tue, Apr 08, 2014 at 08:26:09AM -0700, Linus Torvalds wrote:
> On Mon, Apr 7, 2014 at 1:19 PM, Michal Marek wrote:
> > besides the kbuild branch, here is the LTO build support by Andi. It is
> > a separate branch, because it depends on other patches by Andi which
> > were merged through other trees. The link-time-optimization build is an
> > experimental feature, so there one kconfig option to enable it and
> > another kconfig option to disable it (behind a door with a sign "Beware
> > of the Leopard"...), so that it is not enabled by
> > allmodconfig/allyesconfig.
>
> So right now, I see several reasons not to merge it ("It's so
> experimental that we don't even want to encourage people to test it"
> to "it's not fully fleshed out yet and makes compile times _much_
> longer").
>
> And yet nobody has actually talked about why I *should* merge it.
>
> Which - I think understandably - makes me less than enthusiastic.
>
> So I think I'll let this wait a bit longer, _unless_ people start
> talking about the upsides. How much smaller is the end result? How
> much faster is it? How much more beautiful is it? Does it make new
> cool things possible? Are those cool things really close on the
> horizon and really want this merged even though it's not really quite
> ready yet?
>
> So please: convince me.
I'd really like to see this feature go in to enable ongoing efforts to
make the kernel much smaller, so I'll give it a shot:
In addition to making the kernel smaller and such (I'll leave the
specific stats there to Andi), here's the key awesomeness of LTO that
you, personally, should find useful and compelling: LTO will eliminate
the need to add many lower-level Kconfig symbols to compile out bits of
the kernel. Normally, compiling out a piece of kernel infrastructure
requires adding a kernel config symbol for that infrastructure, and
making all the other kernel bits that use that infrastructure depend on
it (which is an extra step beyond just "include the header and use it").
LTO will allow the compiler to automatically drop bits of infrastructure
(such as bits of lib/, kernel/, etc) that aren't used.
And with some additional GCC smarts (which exist today for C++ classes,
but would need adding for C structure-of-function-pointers objects), GCC
with LTO could even optimize away functions that are only used in the
function pointer of a data structure for which there are no callers.
So, it'd be possible to compile out high-level user-facing items like
syscalls, and have all the infrastructure go away all the way down.
So, with LTO merged, the next time you see a patch to add yet another
Kconfig symbol to compile out some low-level kernel infrastructure when
not needed, you can say "no, I don't want to add more configuration
complexity; compile out the high-level bits and use LTO to make the
compiler drop the infrastructure". And we can potentially start ripping
out *existing* Kconfig infrastructure symbols like that, too.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bug: Fix CONFIG_BUG=n BUG_ON()
On Thu, Jun 19, 2014 at 07:00:14PM +0200, Arnd Bergmann wrote:
> On Thursday 19 June 2014 15:28:19 Bart Van Assche wrote:
> > Patch "bug: Make BUG() always stop the machine" changed the
> > behavior of BUG() with CONFIG_BUG=n from a no-op into an infinite
> > loop. Modify the definition of BUG_ON() accordingly such that the
> > behavior of BUG_ON(1) is identical to that of BUG().
> >
> > Signed-off-by: Bart Van Assche
> > Cc: Arnd Bergmann
> > Cc: Josh Triplett
> > Cc: Andrew Morton
> > ---
> > include/asm-generic/bug.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> > index 630dd23..f3241cd 100644
> > --- a/include/asm-generic/bug.h
> > +++ b/include/asm-generic/bug.h
> > @@ -142,7 +142,7 @@ extern void warn_slowpath_null(const char *file, const
> > int line);
> > #endif
> >
> > #ifndef HAVE_ARCH_BUG_ON
> > -#define BUG_ON(condition) do { if (condition) ; } while (0)
> > +#define BUG_ON(condition) do { } while (unlikely(condition))
> > #endif
> >
> > #ifndef HAVE_ARCH_WARN_ON
> >
>
> How about making it
>
> do { if (condition) BUG(); } while (0)
>
> That way it can be optimized for architectures that have their own
> BUG but not BUG_ON.
That's exactly what BUG_ON becomes if CONFIG_BUG=y, and that
significantly increases kernel size; if you want that, set CONFIG_BUG=y.
BUG_ON should continue to compile to nothing if CONFIG_BUG=n, or
CONFIG_BUG=n has no reason to exist.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bug: Fix CONFIG_BUG=n BUG_ON()
On Thu, Jun 19, 2014 at 07:51:42PM +0200, Bart Van Assche wrote: > On 06/19/14 19:21, j...@joshtriplett.org wrote: > > That's exactly what BUG_ON becomes if CONFIG_BUG=y, and that > > significantly increases kernel size; if you want that, set CONFIG_BUG=y. > > BUG_ON should continue to compile to nothing if CONFIG_BUG=n, or > > CONFIG_BUG=n has no reason to exist. > > Hello Josh, > > I wasn't aware that the current behavior of BUG_ON() with CONFIG_BUG=n > was intentional. The reason I started looking into this is because > different compiler warnings are generated for code with BUG_ON(1) > statements when building against a kernel with CONFIG_BUG=y or > CONFIG_BUG=n. There is an easy alternative though: changing BUG_ON(1) > into BUG() in my code. You should definitely never use BUG_ON(1); use BUG() if you want to say "this (and the code after it) should never be reached". That should also avoid the compiler warnings. If you encounter any compiler warnings caused by CONFIG_BUG=n that go away with CONFIG_BUG=y, please do report them; those should get fixed. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] wlan-ng/prism2mgmt:checkpatch: Fix string split
On Thu, Jun 19, 2014 at 09:20:14PM +0200, Johannes Stadlinger wrote:
> This patch fixes all warnings of checkpatch about string splitting.
>
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Maximilian Eschenbacher
> CC: linux-ker...@i4.cs.fau.de
> CC: Greg Kroah-Hartman
> CC: Himangi Saraogi
> CC: Josh Triplett
> CC: Vitaly Osipov
> CC: de...@driverdev.osuosl.org
> CC: linux-kernel@vger.kernel.org
Reviewed-by: Josh Triplett
> drivers/staging/wlan-ng/prism2mgmt.c | 26 ++
> 1 file changed, 10 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
> b/drivers/staging/wlan-ng/prism2mgmt.c
> index 36a3e1a..f90f7da 100644
> --- a/drivers/staging/wlan-ng/prism2mgmt.c
> +++ b/drivers/staging/wlan-ng/prism2mgmt.c
> @@ -178,8 +178,7 @@ int prism2mgmt_scan(wlandevice_t *wlandev, void *msgp)
>word);
> if (result) {
> netdev_warn(wlandev->netdev,
> - "Passive scan not supported with "
> - "current firmware. (<1.5.1)\n");
> + "Passive scan not supported with current
> firmware. (<1.5.1)\n");
> }
> }
>
> @@ -381,8 +380,7 @@ int prism2mgmt_scan_results(wlandevice_t *wlandev, void
> *msgp)
>
> if (!hw->scanresults) {
> netdev_err(wlandev->netdev,
> -"dot11req_scan_results can only be used after "
> -"a successful dot11req_scan.\n");
> +"dot11req_scan_results can only be used after a
> successful dot11req_scan.\n");
> result = 2;
> req->resultcode.data = P80211ENUM_resultcode_invalid_parameters;
> goto exit;
> @@ -733,8 +731,8 @@ int prism2mgmt_readpda(wlandevice_t *wlandev, void *msgp)
> HFA384x_PDA_LEN_MAX);
> if (result) {
> netdev_err(wlandev->netdev,
> -"hfa384x_drvr_readpda() failed, "
> -"result=%d\n", result);
> +"hfa384x_drvr_readpda() failed, result=%d\n",
> +result);
>
> msg->resultcode.data =
> P80211ENUM_resultcode_implementation_failure;
> @@ -782,8 +780,7 @@ int prism2mgmt_ramdl_state(wlandevice_t *wlandev, void
> *msgp)
>
> if (wlandev->msdstate != WLAN_MSD_FWLOAD) {
> netdev_err(wlandev->netdev,
> -"ramdl_state(): may only be called "
> -"in the fwload state.\n");
> +"ramdl_state(): may only be called in the fwload
> state.\n");
> msg->resultcode.data =
> P80211ENUM_resultcode_implementation_failure;
> msg->resultcode.status = P80211ENUM_msgitem_status_data_ok;
> @@ -841,8 +838,7 @@ int prism2mgmt_ramdl_write(wlandevice_t *wlandev, void
> *msgp)
>
> if (wlandev->msdstate != WLAN_MSD_FWLOAD) {
> netdev_err(wlandev->netdev,
> -"ramdl_write(): may only be called "
> -"in the fwload state.\n");
> +"ramdl_write(): may only be called in the fwload
> state.\n");
> msg->resultcode.data =
> P80211ENUM_resultcode_implementation_failure;
> msg->resultcode.status = P80211ENUM_msgitem_status_data_ok;
> @@ -901,8 +897,7 @@ int prism2mgmt_flashdl_state(wlandevice_t *wlandev, void
> *msgp)
>
> if (wlandev->msdstate != WLAN_MSD_FWLOAD) {
> netdev_err(wlandev->netdev,
> -"flashdl_state(): may only be called "
> -"in the fwload state.\n");
> +"flashdl_state(): may only be called in the fwload
> state.\n");
> msg->resultcode.data =
> P80211ENUM_resultcode_implementation_failure;
> msg->resultcode.status = P80211ENUM_msgitem_status_data_ok;
> @@ -936,8 +931,8 @@ int prism2mgmt_flashdl_state(wlandevice_t *wlandev, void
> *msgp)
> result = prism2sta_ifstate(wlandev, P80211ENUM_ifstate_fwload);
> if (result != P80211ENUM_resultcode_success) {
> netdev_err(wlandev->netdev,
> -
Re: [PATCH 3/8] wlan-ng/prism2mgmt:checkpatch: Insert blank line
On Thu, Jun 19, 2014 at 09:20:15PM +0200, Johannes Stadlinger wrote:
> This patch inserts a blank line after a declaration to avoid checkpatch
> warning.
>
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Maximilian Eschenbacher
> CC: linux-ker...@i4.cs.fau.de
> CC: Greg Kroah-Hartman
> CC: Josh Triplett
> CC: Himangi Saraogi
> CC: Vitaly Osipov
> CC: de...@driverdev.osuosl.org
> CC: linux-kernel@vger.kernel.org
This is one case where I think checkpatch is just wrong; this doesn't
make the code any more (or less) readable.
Meh-by: Josh Triplett
> drivers/staging/wlan-ng/prism2mgmt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
> b/drivers/staging/wlan-ng/prism2mgmt.c
> index f90f7da..e6a82d3 100644
> --- a/drivers/staging/wlan-ng/prism2mgmt.c
> +++ b/drivers/staging/wlan-ng/prism2mgmt.c
> @@ -190,6 +190,7 @@ int prism2mgmt_scan(wlandevice_t *wlandev, void *msgp)
> word = 0;
> for (i = 0; i < msg->channellist.data.len; i++) {
> u8 channel = msg->channellist.data.data[i];
> +
> if (channel > 14)
> continue;
> /* channel 1 is BIT 0 ... channel 14 is BIT 13 */
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] wlan-ng/prism2mib:checkpatch: Fix string split
On Thu, Jun 19, 2014 at 09:20:16PM +0200, Johannes Stadlinger wrote:
> This patch fixes a warning of checkpatch about string splitting.
>
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Maximilian Eschenbacher
> CC: linux-ker...@i4.cs.fau.de
> CC: Greg Kroah-Hartman
> CC: Josh Triplett
> CC: Vitaly Osipov
> CC: Himangi Saraogi
> CC: de...@driverdev.osuosl.org
> CC: linux-kernel@vger.kernel.org
Reviewed-by: Josh Triplett
> drivers/staging/wlan-ng/prism2mib.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/wlan-ng/prism2mib.c
> b/drivers/staging/wlan-ng/prism2mib.c
> index 0fb42df..bdd3b4c 100644
> --- a/drivers/staging/wlan-ng/prism2mib.c
> +++ b/drivers/staging/wlan-ng/prism2mib.c
> @@ -672,8 +672,8 @@ static int prism2mib_fragmentationthreshold(struct mibrec
> *mib,
>
> if (!isget)
> if ((*uint32) % 2) {
> - netdev_warn(wlandev->netdev, "Attempt to set odd number
> "
> -"FragmentationThreshold\n");
> + netdev_warn(wlandev->netdev,
> + "Attempt to set odd number
> FragmentationThreshold\n");
> msg->resultcode.data =
> P80211ENUM_resultcode_not_supported;
> return 0;
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] wlan-ng/prism2mib:checkpatch: Insert blank lines
On Thu, Jun 19, 2014 at 09:20:17PM +0200, Johannes Stadlinger wrote:
> This patch inserts blank lines after declarations to avoid checkpatch
> warning.
>
> After our fixes in 'wlan-ng/prism2mib.c' there are still two checkpatch
> warnings about lines over 80 characters remaining.
>
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Maximilian Eschenbacher
> CC: linux-ker...@i4.cs.fau.de
> CC: Greg Kroah-Hartman
> CC: Josh Triplett
> CC: Vitaly Osipov
> CC: Himangi Saraogi
> CC: de...@driverdev.osuosl.org
> CC: linux-kernel@vger.kernel.org
> ---
> drivers/staging/wlan-ng/prism2mib.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wlan-ng/prism2mib.c
> b/drivers/staging/wlan-ng/prism2mib.c
> index bdd3b4c..3ea24d6 100644
> --- a/drivers/staging/wlan-ng/prism2mib.c
> +++ b/drivers/staging/wlan-ng/prism2mib.c
> @@ -85,7 +85,8 @@ struct mibrec {
> u16 parm1;
> u16 parm2;
> u16 parm3;
> - int (*func) (struct mibrec *mib,
> +
> + int (*func)(struct mibrec *mib,
Eliminating the space here makes sense, but checkpatch shouldn't warn
about spaces after declarations between two fields in the middle of a
structure declaration.
>int isget,
>wlandevice_t *wlandev,
>hfa384x_t *hw,
> @@ -722,6 +723,7 @@ static int prism2mib_priv(struct mibrec *mib,
> switch (mib->did) {
> case DIDmib_lnx_lnxConfigTable_lnxRSNAIE:{
> hfa384x_WPAData_t wpa;
> +
> if (isget) {
> hfa384x_drvr_getconfig(hw,
> HFA384x_RID_CNFWPADATA,
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] rcu: use __this_cpu_read helper instead of per_cpu_ptr(p, raw_smp_processor_id())
On Thu, Jun 19, 2014 at 04:12:46PM -0400, Pranith Kumar wrote:
> Use __this_cpu_read() instead of per_cpu_ptr() for optimized access.
>
> Last time when Shan Wei posted this, you wanted before/after code for ARM and
> x86.
> (http://lkml.iu.edu//hypermail/linux/kernel/1211.2/00498.html).
>
> There are few other location which use per_cpu_ops instead of this_cpu_ops. I
> can convert them accordingly if you are accept this :)
Please do.
> Using gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3, I get (trimmed to relevant
> assembly, from make kernel/rcu/tree.s)
>
> ARMv7 per_cpu_ptr():
>
> force_quiescent_state:
> movr3, sp@,
> bicr1, r3, #8128@ tmp171,,
> ldrr2, .L98@ tmp169,
> bicr1, r1, #63@ tmp170, tmp171,
> ldrr3, [r0, #220]@ __ptr, rsp_6(D)->rda
> ldrr1, [r1, #20]@ D.35903_68->cpu, D.35903_68->cpu
> movr6, r0@ rsp, rsp
> ldrr2, [r2, r1, asl #2]@ tmp173, __per_cpu_offset
> addr3, r3, r2@ tmp175, __ptr, tmp173
> ldrr5, [r3, #12]@ rnp_old, D.29162_13->mynode
>
> ARMv7 using __this_cpu_read():
>
> force_quiescent_state:
> ldrr3, [r0, #220]@ rsp_7(D)->rda, rsp_7(D)->rda
> movr6, r0@ rsp, rsp
> addr3, r3, #12@ __ptr, rsp_7(D)->rda,
> ldrr5, [r2, r3]@ rnp_old, *D.29176_13
>
> Using gcc 4.8.2:
>
> x86_64 per_cpu_ptr():
>
> movl %gs:cpu_number,%edx# cpu_number, pscr_ret__
> movslq%edx, %rdx# pscr_ret__, pscr_ret__
> movq__per_cpu_offset(,%rdx,8), %rdx# __per_cpu_offset, tmp93
> movq%rdi, %r13# rsp, rsp
> movq1000(%rdi), %rax# rsp_9(D)->rda, __ptr
> movq24(%rdx,%rax), %r12# _15->mynode, rnp_old
>
> x86_64 __this_cpu_read():
>
> movq%rdi, %r13# rsp, rsp
> movq1000(%rdi), %rax# rsp_9(D)->rda, rsp_9(D)->rda
> movq %gs:24(%rax),%r12# _10->mynode, rnp_old
>
>
> Signed-off-by: Pranith Kumar
> Signed-off-by: Shan Wei
> Acked-by: Christoph Lameter
Reviewed-by: Josh Triplett
> ---
> kernel/rcu/tree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index f1ba773..c6de285 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2404,7 +2404,7 @@ static void force_quiescent_state(struct rcu_state *rsp)
> struct rcu_node *rnp_old = NULL;
>
> /* Funnel through hierarchy to reduce memory contention. */
> -rnp = per_cpu_ptr(rsp->rda, raw_smp_processor_id())->mynode;
> +rnp = __this_cpu_read(rsp->rda->mynode);
> for (; rnp != NULL; rnp = rnp->parent) {
> ret = (ACCESS_ONCE(rsp->gp_flags) & RCU_GP_FLAG_FQS) ||
>!raw_spin_trylock(&rnp->fqslock);
> --
> 2.0.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] wlan-ng/prism2sta:checkpatch: Fix long lines
On Thu, Jun 19, 2014 at 09:20:18PM +0200, Johannes Stadlinger wrote: > This patch fixes all warning of checkpatch about lines over 80 > characters. > > Signed-off-by: Johannes Stadlinger > Signed-off-by: Maximilian Eschenbacher > CC: linux-ker...@i4.cs.fau.de > CC: Greg Kroah-Hartman > CC: Tugce Sirin > CC: Josh Triplett > CC: Neil Armstrong > CC: Paul Gortmaker > CC: Vitaly Osipov > CC: de...@driverdev.osuosl.org > CC: linux-kernel@vger.kernel.org Most of these look fine, but... > @@ -1271,7 +1275,8 @@ void prism2sta_processing_defer(struct work_struct > *data) >HFA384x_RID_CURRENTSSID, result); > return; > } > - prism2mgmt_bytestr2pstr((struct hfa384x_bytestr *) > &ssid, > + prism2mgmt_bytestr2pstr((struct hfa384x_bytestr *) > + &ssid, > (p80211pstrd_t *) & > wlandev->ssid); ...that (and the one in the subsequent context lines) looks horrible. I'd suggest breaking after the opening parenthesis of the function call and just indenting the arguments by one tab: foo_with_long_name( long_arg, another_long_arg); Better yet, ignore checkpatch and format that call more readably as though the 80 column rule didn't exist. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] wlan-ng/prism2sta:checkpatch: Fix string split
On Thu, Jun 19, 2014 at 09:20:19PM +0200, Johannes Stadlinger wrote: > This patch fixes a warning of checkpatch about string splitting. > > Signed-off-by: Johannes Stadlinger > Signed-off-by: Maximilian Eschenbacher > CC: linux-ker...@i4.cs.fau.de > CC: Greg Kroah-Hartman > CC: Tugce Sirin > CC: Josh Triplett > CC: Vitaly Osipov > CC: Neil Armstrong > CC: Paul Gortmaker > CC: de...@driverdev.osuosl.org > CC: linux-kernel@vger.kernel.org Reviewed-by: Josh Triplett > drivers/staging/wlan-ng/prism2sta.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/staging/wlan-ng/prism2sta.c > b/drivers/staging/wlan-ng/prism2sta.c > index a449fdf..9444006 100644 > --- a/drivers/staging/wlan-ng/prism2sta.c > +++ b/drivers/staging/wlan-ng/prism2sta.c > @@ -468,8 +468,7 @@ u32 prism2sta_ifstate(wlandevice_t *wlandev, u32 ifstate) > break; > case WLAN_MSD_RUNNING: > netdev_warn(wlandev->netdev, > -"Cannot enter fwload state from enable state," > -"you must disable first.\n"); > + "Cannot enter fwload state from enable > state, you must disable first.\n"); > result = P80211ENUM_resultcode_invalid_parameters; > break; > case WLAN_MSD_HWFAIL: > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] wlan-ng/prism2sta:checkpatch: Insert blank lines
On Thu, Jun 19, 2014 at 09:20:20PM +0200, Johannes Stadlinger wrote:
> This patch inserts blank lines after declarations to avoid checkpatch
> warnings.
>
> After our fixes in 'wlan-ng/prism2sta' there is still a checkpatch
> warning about prefering 'ether_addr_copy' instead of 'memcpy'
> remaining.
>
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Maximilian Eschenbacher
> CC: linux-ker...@i4.cs.fau.de
> CC: Greg Kroah-Hartman
> CC: Tugce Sirin
> CC: Josh Triplett
> CC: Himangi Saraogi
> CC: Paul Gortmaker
> CC: Vitaly Osipov
> CC: Neil Armstrong
> CC: de...@driverdev.osuosl.org
> CC: linux-kernel@vger.kernel.org
This one does look like an improvement.
Reviewed-by: Josh Triplett
> drivers/staging/wlan-ng/prism2sta.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/wlan-ng/prism2sta.c
> b/drivers/staging/wlan-ng/prism2sta.c
> index 9444006..8d4d7ba 100644
> --- a/drivers/staging/wlan-ng/prism2sta.c
> +++ b/drivers/staging/wlan-ng/prism2sta.c
> @@ -360,6 +360,7 @@ static int prism2sta_mlmerequest(wlandevice_t *wlandev,
> struct p80211msg *msg)
> case DIDmsg_lnxreq_ifstate:
> {
> struct p80211msg_lnxreq_ifstate *ifstatemsg;
> +
> pr_debug("Received mlme ifstate request\n");
> ifstatemsg = (struct p80211msg_lnxreq_ifstate *) msg;
> result =
> @@ -1411,6 +1412,7 @@ void prism2sta_processing_defer(struct work_struct
> *data)
>*/
> if (hw->join_ap && --hw->join_retries > 0) {
> hfa384x_JoinRequest_data_t joinreq;
> +
> joinreq = hw->joinreq;
> /* Send the join request */
> hfa384x_drvr_setconfig(hw,
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [bisected] pre-3.16 regression on open() scalability
On Thu, Jun 19, 2014 at 04:16:34PM -0500, Christoph Lameter wrote: > This looks very much like the CONFIG_PREEMPT problem in not so > extreme form. Maybe we need to add another config option: > > CONFIG_REALLY_REALLY_NO_PREEMPT > > to get the fastest code possible and those cond_rescheds removed from the > critical paths? > > Or better > > CONFIG_PREEMPT_HALF_WAY > > to enable those cond_rescheds. That much actually does seem quite reasonable: making cond_resched() do non-trivial work ought to have a config option to disable it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 0/5] Fix for cond_resched performance regression
On Fri, Jun 20, 2014 at 11:32:49AM -0700, Paul E. McKenney wrote: > Hello! > > This series contains changes to address the performance regressions > introduced by commit ac1bea85781e (Make cond_resched() report RCU > quiescent states), which was in turn fixing a problem where tasks looping > in the kernel could delay RCU grace periods. The changes in this series > are as follows: > > 1.Reduce the overhead of checking added to cond_resched() and friends. > > 2.Add a new cond_resched_rcu_qs() to provide RCU quiescent states > even if cond_resched() should stop doing so. > > 3.Add a new RCU_COND_RESCHED_QS to prevent cond_resched() from > reporting RCU quiescent states. > > 4.Prevent rcutorture testing from reporting spurious RCU CPU stall > warnings, and also to test RCU_COND_RESCHED_QS. > > 5.Provides a boot/sysfs rcutree.jiffies_till_cond_resched_qs > parameter to replace the magic "7". For all five patches: Reviewed-by: Josh Triplett Glad to see this doesn't add any overhead to rcutiny. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 0/5] Fix for cond_resched performance regression
On Fri, Jun 20, 2014 at 12:12:36PM -0700, Paul E. McKenney wrote: > o Make cond_resched() a no-op for PREEMPT=y. This might well turn > out to be a good thing, but it doesn't help give RCU the quiescent > states that it needs. What about doing this, together with letting the fqs logic poke un-quiesced kernel code as needed? That way, rather than having cond_resched do any work, you have the fqs logic recognize that a particular CPU has gone too long without quiescing, without disturbing that CPU at all if it hasn't gone too long. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 0/5] Fix for cond_resched performance regression
On Fri, Jun 20, 2014 at 03:11:20PM -0700, Paul E. McKenney wrote: > On Fri, Jun 20, 2014 at 02:24:23PM -0700, j...@joshtriplett.org wrote: > > On Fri, Jun 20, 2014 at 12:12:36PM -0700, Paul E. McKenney wrote: > > > o Make cond_resched() a no-op for PREEMPT=y. This might well turn > > > out to be a good thing, but it doesn't help give RCU the quiescent > > > states that it needs. > > > > What about doing this, together with letting the fqs logic poke > > un-quiesced kernel code as needed? That way, rather than having > > cond_resched do any work, you have the fqs logic recognize that a > > particular CPU has gone too long without quiescing, without disturbing > > that CPU at all if it hasn't gone too long. > > My next stop is to post the previous series, but with a couple of > exports and one bug fix uncovered by testing thus far, but after > another round of testing. Then I am going to take a close look at > this one: > > o Push the checks further into cond_resched(), so that the > fastpath does the same sequence of instructions that the original > did. This might work well, but requires IPIs, which are not so > good for latencies on the remote CPU. It nevertheless might be a > decent long-term solution given that if your CPU is spending many > jiffies looping in the kernel, you aren't getting good latencies > anyway. It also has the benefit of allowing RCU to take advantage > of the implicit quiescent states of all cond_resched() calls, > and of eliminating the need for a separate cond_resched_rcu_qs() > and for RCU_COND_RESCHED_QS. > > The one you call out is of course interesting as well. But there are > a couple of questions: > > 1.Why wasn't cond_resched() a no-op in CONFIG_PREEMPT to start > with? It just seems to obvious a thing to do for it to possibly > be an oversight. (What, me paranoid?) > > 2.When RCU recognizes that a particular CPU has gone too long, > exactly what are you suggesting that RCU do about it? When > formulating your answer, please give due consideration to the > implications of that CPU being a NO_HZ_FULL CPU. ;-) Send it an IPI that either causes it to flag a quiescent state immediately if currently quiesced or causes it to quiesce at the next opportunity if not. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 0/5] Fix for cond_resched performance regression
On Fri, Jun 20, 2014 at 04:30:33PM -0700, Paul E. McKenney wrote: > On Fri, Jun 20, 2014 at 03:39:51PM -0700, j...@joshtriplett.org wrote: > > On Fri, Jun 20, 2014 at 03:11:20PM -0700, Paul E. McKenney wrote: > > > On Fri, Jun 20, 2014 at 02:24:23PM -0700, j...@joshtriplett.org wrote: > > > > On Fri, Jun 20, 2014 at 12:12:36PM -0700, Paul E. McKenney wrote: > > > > > o Make cond_resched() a no-op for PREEMPT=y. This might well turn > > > > > out to be a good thing, but it doesn't help give RCU the > > > > > quiescent > > > > > states that it needs. > > > > > > > > What about doing this, together with letting the fqs logic poke > > > > un-quiesced kernel code as needed? That way, rather than having > > > > cond_resched do any work, you have the fqs logic recognize that a > > > > particular CPU has gone too long without quiescing, without disturbing > > > > that CPU at all if it hasn't gone too long. > > > > > > My next stop is to post the previous series, but with a couple of > > > exports and one bug fix uncovered by testing thus far, but after > > > another round of testing. Then I am going to take a close look at > > > this one: > > > > > > o Push the checks further into cond_resched(), so that the > > > fastpath does the same sequence of instructions that the original > > > did. This might work well, but requires IPIs, which are not so > > > good for latencies on the remote CPU. It nevertheless might be a > > > decent long-term solution given that if your CPU is spending many > > > jiffies looping in the kernel, you aren't getting good latencies > > > anyway. It also has the benefit of allowing RCU to take advantage > > > of the implicit quiescent states of all cond_resched() calls, > > > and of eliminating the need for a separate cond_resched_rcu_qs() > > > and for RCU_COND_RESCHED_QS. > > > > > > The one you call out is of course interesting as well. But there are > > > a couple of questions: > > > > > > 1.Why wasn't cond_resched() a no-op in CONFIG_PREEMPT to start > > > with? It just seems to obvious a thing to do for it to possibly > > > be an oversight. (What, me paranoid?) > > > > > > 2.When RCU recognizes that a particular CPU has gone too long, > > > exactly what are you suggesting that RCU do about it? When > > > formulating your answer, please give due consideration to the > > > implications of that CPU being a NO_HZ_FULL CPU. ;-) > > > > Send it an IPI that either causes it to flag a quiescent state > > immediately if currently quiesced or causes it to quiesce at the next > > opportunity if not. > > OK. But if we are in a !PREEMPT kernel, That's not the case I was suggesting. *If* the kernel is fully preemptible, then it makes little sense to put any code in cond_resched, when instead another thread can simply cause a preemption if it needs a quiescent state. That has the advantage of not imposing any unnecessary polling on code running in the kernel. In a !PREEMPT kernel, it makes a bit more sense to have cond_resched as a voluntary preemption point. But voluntary preemption points don't make as much sense in a kernel prepared to preempt a thread anywhere. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] rcutorture: use bash shell for all the test scripts
On Fri, Jul 11, 2014 at 05:31:27PM -0400, Pranith Kumar wrote: > Some of the scripts encode a default /bin/sh shell. On systems which use dash > as > default shell, these scripts fail as they are bash scripts. I encountered this > while testing the sprintf() changes on a Debian system where dash is the > default > shell. > > This commit changes all such uses to use bash explicitly. Good catch. Since these all have #! lines, can you please set the executable bit on any that don't have it set (looks like just config2frag.sh and kvm.sh), and then change the Usage lines to drop the shell entirely and just invoke the program directly? > Signed-off-by: Pranith Kumar With the above changed (perhaps in a separate patch): Reviewed-by: Josh Triplett > tools/testing/selftests/rcutorture/bin/config2frag.sh | 4 ++-- > tools/testing/selftests/rcutorture/bin/configcheck.sh | 4 ++-- > tools/testing/selftests/rcutorture/bin/configinit.sh | 4 ++-- > tools/testing/selftests/rcutorture/bin/kvm-build.sh| 2 +- > tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh | 2 +- > tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh | 2 +- > tools/testing/selftests/rcutorture/bin/kvm-recheck.sh | 2 +- > tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 2 +- > tools/testing/selftests/rcutorture/bin/kvm.sh | 2 +- > tools/testing/selftests/rcutorture/bin/parse-build.sh | 4 ++-- > tools/testing/selftests/rcutorture/bin/parse-console.sh| 4 ++-- > tools/testing/selftests/rcutorture/bin/parse-torture.sh| 4 ++-- > 12 files changed, 18 insertions(+), 18 deletions(-) > > diff --git a/tools/testing/selftests/rcutorture/bin/config2frag.sh > b/tools/testing/selftests/rcutorture/bin/config2frag.sh > index 9f9ffcd..4e394ef 100644 > --- a/tools/testing/selftests/rcutorture/bin/config2frag.sh > +++ b/tools/testing/selftests/rcutorture/bin/config2frag.sh > @@ -1,5 +1,5 @@ > -#!/bin/sh > -# Usage: sh config2frag.sh < .config > configfrag > +#!/bin/bash > +# Usage: bash config2frag.sh < .config > configfrag > # > # Converts the "# CONFIG_XXX is not set" to "CONFIG_XXX=n" so that the > # resulting file becomes a legitimate Kconfig fragment. > diff --git a/tools/testing/selftests/rcutorture/bin/configcheck.sh > b/tools/testing/selftests/rcutorture/bin/configcheck.sh > index d686537..6173ed5 100755 > --- a/tools/testing/selftests/rcutorture/bin/configcheck.sh > +++ b/tools/testing/selftests/rcutorture/bin/configcheck.sh > @@ -1,5 +1,5 @@ > -#!/bin/sh > -# Usage: sh configcheck.sh .config .config-template > +#!/bin/bash > +# Usage: bash configcheck.sh .config .config-template > # > # This program is free software; you can redistribute it and/or modify > # it under the terms of the GNU General Public License as published by > diff --git a/tools/testing/selftests/rcutorture/bin/configinit.sh > b/tools/testing/selftests/rcutorture/bin/configinit.sh > index 9c3f3d3..d8f7418 100755 > --- a/tools/testing/selftests/rcutorture/bin/configinit.sh > +++ b/tools/testing/selftests/rcutorture/bin/configinit.sh > @@ -1,6 +1,6 @@ > -#!/bin/sh > +#!/bin/bash > # > -# sh configinit.sh config-spec-file [ build output dir ] > +# bash configinit.sh config-spec-file [ build output dir ] > # > # Create a .config file from the spec file. Run from the kernel source tree. > # Exits with 0 if all went well, with 1 if all went well but the config > diff --git a/tools/testing/selftests/rcutorture/bin/kvm-build.sh > b/tools/testing/selftests/rcutorture/bin/kvm-build.sh > index 7c1e56b..e4bfb91 100755 > --- a/tools/testing/selftests/rcutorture/bin/kvm-build.sh > +++ b/tools/testing/selftests/rcutorture/bin/kvm-build.sh > @@ -2,7 +2,7 @@ > # > # Build a kvm-ready Linux kernel from the tree in the current directory. > # > -# Usage: sh kvm-build.sh config-template build-dir more-configs > +# Usage: bash kvm-build.sh config-template build-dir more-configs > # > # This program is free software; you can redistribute it and/or modify > # it under the terms of the GNU General Public License as published by > diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh > b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh > index 7f1ff1a..30cbb63 100755 > --- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh > +++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh > @@ -2,7 +2,7 @@ > # > # Analyze a given results directory for locktorture progress. > # > -# Usage: sh kvm-recheck-lock.sh resdir > +# Usage: bash kvm-recheck-lock.sh resdir > # > # This program is free software; you can redistribute it and/or modify > # it und
Re: [PATCH tip/core/rcu 2/3] rcu: Add designated reviewers for RCU
On Tue, Jul 08, 2014 at 09:09:25PM -0700, Joe Perches wrote: > On Tue, 2014-07-08 at 15:25 -0700, Paul E. McKenney wrote: > > On Tue, Jul 08, 2014 at 03:05:16PM -0700, Joe Perches wrote: > [] > > > I still think the concept is pretty useless and it's > > > just a duplication of "M:", which isn't anything other > > > than a list of who should be sent patches. > [] > > It will be interesting to see how things go. > > Yes, it might work out fine and maybe might cause some > other beneficial changes. > > > There did seem to be > > some people who were comfortable being listed as RCU reviewers, but > > not as RCU maintainers. Perhaps the same thing happens elsewhere. > > Maybe so. > > I wrote a script to find which maintainer addresses that > haven't signed or authored a commit in the last 2 years. Did you count Acked-by or Reviewed-by lines as maintainer activity as well? I do see a few cases of stale email addresses in there, for active developers who don't use the listed email address. Myself included (I don't use @freedesktop.org anymore, though it still works). I also see a few lists or role addresses: ceph-devel and triv...@kernel.org seem unlikely to author commits. > I got ~250 entries. That's about 1/4 of all maintainer > email addresses. > > Maybe a dozen of these are false positives though because > some maintainers prefer to receive email at one address > but ack from another. > > These are all lowercase for better matching. > > abhijit mahajan > achim leubner > adam radford > al cho > ali akcaagac > allan stephens > aloisio almeida jr > andreas dilger > andreas koensgen > andrew hendry > andrew veliath > andries brouwer > andy henroid > anil ravindranath > anil s keshavamurthy > antoine jacquet > antonino daplas > armin schindler > artur paszkiewicz > "arvind r." > ashley lai > aurelien jacquiot > balbir singh > bill metzenthen > bradley grove > brett rudley > brian johnson > bruce chang > bryan huntsman > ceph-de...@vger.kernel.org > cesar miquel > cezary jackiewicz > chaoming li > chen liqin > chien yen > chirag kantharia > chris brannon > christine caulfield > christopher harrer > "christopher li" > christoph raisch > cliff whickman > colin leroy > corentin labbe > daniel drake > daniele venzano > daniel oliveira nascimento > daniel ribeiro > dario ballabio > david kershner > david rowe > david safford > david täht > deepak saxena > dirk eibach > dirk opfer > dmitry tarnyagin > dominik brodowski > doug gilbert > doug thompson > doug warzecha > duncan sands > "ed l. cashin" > egor martovetsky > eric biederman > eric piel > erik andren > faisal latif > ferenc bakonyi > florian schilhabel . > forest bond > frank seidel > fujita tomonori > gary zambrano > gilles muller > gleb natapov > guillaume ligneul > guo-fu tseng > gustavo padovan > haavard skinnemoen > hal rosenstock > hansjoerg lipp > hans ulli kroll > harald welte > harald welte > henk vergonet > henrique de moraes holschuh > herton ronaldo krzesinski > heungjun kim > hideaki yoshifuji > hoang-nam nguyen > hubert feurstein > "hung hing lun, mike" > ian campbell > ian molton > ion badulescu > ishizaki kou > ivan kokshaysky > jakub schmidtke > "james e.j. bottomley" > "james e.j. bottomley" > "james e.j. bottomley" > james morris > "james r. van zandt" > jamie lenehan > jan-benedict glaw > jan dumon > jan harkes > jan-simon moeller > jarkko lavinen > jarod wilson > jason uhlenkott > jaya kumar > jaya kumar > jay cliburn > jean-paul roubelat > jeff dike > jens osterkamp > jes sorensen > jim paris > jiri kosina > jiri slaby > joerg reuter > joern engel > johan hedberg > john mccutchan > john ronciak > "john w. linville" > jonathan buzzard > "jon d. mason" > jon nettleton > josh triplett > joshua morris > joshua thompson > juanjo ciarlante > "juergen e. fischer" > juergen stuber > juerg haefliger > kentaro takeda > kevin curtis > kevin hilman > kirk reiser > koichi yasutake > kristoffer glembo > kurt garloff > leandro costantino > len brown > lennert buytenhek > liam girdwood > liam girdwood > lior dotan > "luis r. rodriguez" > maik broemme >
Re: [PATCH tip/core/rcu 2/3] rcu: Add designated reviewers for RCU
On Thu, Jul 10, 2014 at 03:00:12AM -0700, Joe Perches wrote: > On Thu, 2014-07-10 at 11:39 +0200, Peter Zijlstra wrote: > > On Wed, Jul 09, 2014 at 06:23:22AM -0700, Joe Perches wrote: > > > > SCHEDULER: > > > > ... > > > > R: Steven Rostedt (kernel/sched/rt.c) > > > > R: Juri Lelli (kernel/sched/deadline.c) > > > > > > Maybe a better syntax might be something like: > > > R:Steven Rostedt > > > F: kernel/sched/rt.c > > > > > > where optional F:/X: lines override the default > > > assumption of all F:/X: from the section. > > > > Would RF: make sense? Instead of the indenting. > > Maybe. > > As a preface: > > I doubt the need for associating a subset of the files > patterns for a subsystem with a particular reviewer. > > If a reviewer is interested enough in a subsystem to > volunteer to read patches then that reviewer likely won't > be overburdened by getting a few more emailed patches > that may be outside a scope of interest. I agree. And if a subset of files needs a separate set of maintainers or reviewers, it doesn't seem excessive to split it into a separate MAINTAINERS entry. For instance, if you want kernel/sched/rt.c to have an additional set of maintainers/reviewers, just add a MAINTAINERS entry for "SCHEDULER - REALTIME" with an appropriate "F:" line. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] rcu: tiny.c: Update reference to tree.c
On Tue, Jul 15, 2014 at 06:31:47PM -0400, Pranith Kumar wrote:
> This commit updates the references to rcutree.c which is now rcu/tree.c
>
> Signed-off-by: Pranith Kumar
Reviewed-by: Josh Triplett
> kernel/rcu/tiny.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
> index d9efcc1..6bd785c 100644
> --- a/kernel/rcu/tiny.c
> +++ b/kernel/rcu/tiny.c
> @@ -51,7 +51,7 @@ static long long rcu_dynticks_nesting =
> DYNTICK_TASK_EXIT_IDLE;
>
> #include "tiny_plugin.h"
>
> -/* Common code for rcu_idle_enter() and rcu_irq_exit(), see
> kernel/rcutree.c. */
> +/* Common code for rcu_idle_enter() and rcu_irq_exit(), see
> kernel/rcu/tree.c. */
> static void rcu_idle_enter_common(long long newval)
> {
> if (newval) {
> @@ -114,7 +114,7 @@ void rcu_irq_exit(void)
> }
> EXPORT_SYMBOL_GPL(rcu_irq_exit);
>
> -/* Common code for rcu_idle_exit() and rcu_irq_enter(), see
> kernel/rcutree.c. */
> +/* Common code for rcu_idle_exit() and rcu_irq_enter(), see
> kernel/rcu/tree.c. */
> static void rcu_idle_exit_common(long long oldval)
> {
> if (oldval) {
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] rcu: Remove stale comment in tree.c
On Tue, Jul 15, 2014 at 06:31:48PM -0400, Pranith Kumar wrote: > This commit removes a stale comment in rcu/tree.c. > FYI, an updated comment exists a few lines below this. > > Signed-off-by: Pranith Kumar In general, when removing a stale comment, I'd suggest explaining why the comment is stale. Was code removed without removing the corresponding comment, or was code changed such that the comment no longer applies, or...? - Josh Triplett > kernel/rcu/tree.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index a1abaa8..e67246e 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -2211,8 +2211,6 @@ static void rcu_cleanup_dead_cpu(int cpu, struct > rcu_state *rsp) > /* Adjust any no-longer-needed kthreads. */ > rcu_boost_kthread_setaffinity(rnp, -1); > > - /* Remove the dead CPU from the bitmasks in the rcu_node hierarchy. */ > - > /* Exclude any attempts to start a new grace period. */ > mutex_lock(&rsp->onoff_mutex); > raw_spin_lock_irqsave(&rsp->orphan_lock, flags); > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] rcu: Use rcu_num_nodes instead of NUM_RCU_NODES
On Tue, Jul 15, 2014 at 06:31:49PM -0400, Pranith Kumar wrote:
> NUM_RCU_NODES is set at build time and is usually a huge number. We calculate
> the
> actual number of rcu nodes necessary at boot time based on nr_cpu_ids in
> rcu_init_geometry() and store it in rcu_num_nodes. We should use this variable
> instead of NUM_RCU_NODES.
>
> This commit changes all such uses of NUM_RCU_NODES to rcu_num_nodes.
>
> Signed-off-by: Pranith Kumar
Reviewed-by: Josh Triplett
(On a separate note, these names really need to provide clearer
explanations of the difference, grumble. Case and word order explains
little.)
> kernel/rcu/tree_plugin.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index cedb020..17ccb62 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -46,6 +46,8 @@ static bool __read_mostly rcu_nocb_poll;/* Offload
> kthread are to poll. */
> static char __initdata nocb_buf[NR_CPUS * 5];
> #endif /* #ifdef CONFIG_RCU_NOCB_CPU */
>
> +extern int rcu_num_nodes;
> +
> /*
> * Check the RCU kernel configuration parameters and print informative
> * messages about anything out of the ordinary. If you like #ifdef, you
> @@ -885,7 +887,7 @@ void synchronize_rcu_expedited(void)
> /* Snapshot current state of ->blkd_tasks lists. */
> rcu_for_each_leaf_node(rsp, rnp)
> sync_rcu_preempt_exp_init(rsp, rnp);
> - if (NUM_RCU_NODES > 1)
> + if (rcu_num_nodes > 1)
> sync_rcu_preempt_exp_init(rsp, rcu_get_root(rsp));
>
> put_online_cpus();
> @@ -1475,7 +1477,7 @@ static void __init rcu_spawn_boost_kthreads(void)
> BUG_ON(smpboot_register_percpu_thread(&rcu_cpu_thread_spec));
> rnp = rcu_get_root(rcu_state_p);
> (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
> - if (NUM_RCU_NODES > 1) {
> + if (rcu_num_nodes > 1) {
> rcu_for_each_leaf_node(rcu_state_p, rnp)
> (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
> }
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] rcu: Remove stale comment in tree.c
On Wed, Jul 16, 2014 at 09:29:18AM -0400, Pranith Kumar wrote: > On 07/16/2014 08:47 AM, Paul E. McKenney wrote: > > On Tue, Jul 15, 2014 at 06:57:59PM -0400, Pranith Kumar wrote: > >> > >> On 07/15/2014 06:53 PM, j...@joshtriplett.org wrote: > >>> On Tue, Jul 15, 2014 at 06:31:48PM -0400, Pranith Kumar wrote: > >>>> This commit removes a stale comment in rcu/tree.c. > >>>> FYI, an updated comment exists a few lines below this. > >>>> > >>>> Signed-off-by: Pranith Kumar > >>> In general, when removing a stale comment, I'd suggest explaining why > >>> the comment is stale. Was code removed without removing the > >>> corresponding comment, or was code changed such that the comment no > >>> longer applies, or...? > >> > >> I guess it was left out when code was moved around previously. And I did > >> mention that an updated comment is there a few lines below. > >> > >> For reference this is the new comment which is below the old comment, they > >> mean the same :) > >> > >> /* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */ > > > > Indeed that is the case. > > > > Please update the commit log with this explanation and resend. > > > > Thanx, Paul > > > > Please find the updated patch below. > > -- > Pranith > > From: Pranith Kumar > Date: Mon, 14 Jul 2014 16:01:05 -0400 > Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c > > This commit removes a stale comment in rcu/tree.c which was left out when some > code was moved around previously. > > For reference, the following updated comment exists a few lines below this > which > means the same. > > /* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */ > > Signed-off-by: Pranith Kumar Reviewed-by: Josh Triplett > kernel/rcu/tree.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index a1abaa8..e67246e 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -2211,8 +2211,6 @@ static void rcu_cleanup_dead_cpu(int cpu, struct > rcu_state *rsp) > /* Adjust any no-longer-needed kthreads. */ > rcu_boost_kthread_setaffinity(rnp, -1); > > - /* Remove the dead CPU from the bitmasks in the rcu_node hierarchy. */ > - > /* Exclude any attempts to start a new grace period. */ > mutex_lock(&rsp->onoff_mutex); > raw_spin_lock_irqsave(&rsp->orphan_lock, flags); > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 4/5] kernel/rcu/tree.c:3435 fix a sparse warning
On Wed, Jun 11, 2014 at 04:39:42PM -0400, Pranith Kumar wrote:
> kernel/rcu/tree.c:3435:21: warning: incorrect type in argument 1 (different
> modifiers)
> kernel/rcu/tree.c:3435:21:expected int ( *threadfn )( ... )
> kernel/rcu/tree.c:3435:21:got int ( static [toplevel] [noreturn]
> * )( ... )
>
> by removing __noreturn attribute and adding unreachable() as suggested on the
> mailing list: http://www.kernelhub.org/?p=2&msg=436683
>
> Signed-off-by: Pranith Kumar
No, we should not do this. And the mailing list post you point to seems
to explicitly recommend using noreturn rather than unreachable.
If sparse doesn't understand this, that's a bug in sparse, not in the
kernel. Sparse needs to understand that it's OK to drop noreturn from a
function pointer type, just not OK to add it.
Rationale: If you call a noreturn function through a non-noreturn
function pointer, you might end up with unnecessary cleanup code, but
the call will work. If you call a non-noreturn function through a
noreturn function pointer, the caller will not expect a return, and may
crash; *that* should require a cast.
> kernel/rcu/tree.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 9ab84d3..6029a2e 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1689,7 +1689,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
> /*
> * Body of kthread that handles grace periods.
> */
> -static int __noreturn rcu_gp_kthread(void *arg)
> +static int rcu_gp_kthread(void *arg)
> {
> int fqs_state;
> int gf;
> @@ -1777,6 +1777,9 @@ static int __noreturn rcu_gp_kthread(void *arg)
> /* Handle grace-period end. */
> rcu_gp_cleanup(rsp);
> }
> +
> + unreachable();
> + return 0;
> }
>
> /*
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/5] kernel/rcu/rcutorture.c:185 fix a sparse warning
On Wed, Jun 11, 2014 at 04:39:43PM -0400, Pranith Kumar wrote: > fix the following sparse warning > > kernel/rcu/rcutorture.c:185:1: warning: symbol 'boost_mutex' was not > declared. Should it be static? > > by marking boost_mutex as a static mutex > > Signed-off-by: Pranith Kumar Please preserve the comment alignment (by deleting a tab). With that fixed: Reviewed-by: Josh Triplett > kernel/rcu/rcutorture.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c > index 7fa34f8..1cd4b2d 100644 > --- a/kernel/rcu/rcutorture.c > +++ b/kernel/rcu/rcutorture.c > @@ -182,7 +182,7 @@ static u64 notrace rcu_trace_clock_local(void) > #endif /* #else #ifdef CONFIG_RCU_TRACE */ > > static unsigned long boost_starttime;/* jiffies of next boost test > start. */ > -DEFINE_MUTEX(boost_mutex); /* protect setting boost_starttime */ > +static DEFINE_MUTEX(boost_mutex);/* protect setting > boost_starttime */ > /* and boost task create/destroy. */ > static atomic_t barrier_cbs_count; /* Barrier callbacks registered. */ > static bool barrier_phase; /* Test phase. */ > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Documentation: exceptions to what I maintain
On Thu, Jun 12, 2014 at 10:12:57AM -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Note that I don't maintain Documentation/ABI/, > Documentation/devicetree/, or the language translation files. > > Signed-off-by: Randy Dunlap One comment below. > MAINTAINERS |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- lnx-315-rc5.orig/MAINTAINERS > +++ lnx-315-rc5/MAINTAINERS > @@ -2885,7 +2885,7 @@ M: Randy Dunlap > L: linux-...@vger.kernel.org > T: quilt http://www.infradead.org/~rdunlap/Doc/patches/ > S: Maintained > -F: Documentation/ > +F: Documentation/ (but not: ABI, devicetree, translations) Could we make this machine-readable, and teach scripts/get_maintainer.pl to understand it? Two possible syntaxes: F: Documentation/ F: !Documentation/ABI/ ... or: F: Documentation/ (not Documentation/ABI ...) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Documentation: exceptions to what I maintain
On Thu, Jun 12, 2014 at 10:49:20AM -0700, Randy Dunlap wrote: > On 06/12/14 10:35, Joe Perches wrote: > > On Thu, 2014-06-12 at 10:12 -0700, Randy Dunlap wrote: > >> From: Randy Dunlap > >> > >> Note that I don't maintain Documentation/ABI/, > >> Documentation/devicetree/, or the language translation files. > >> > >> Signed-off-by: Randy Dunlap > > > > Hey Randy. > > > > Perhaps it's better to use exclusion "X:" values > > so get_maintainer doesn't still include you. > > > >> @@ -2885,7 +2885,7 @@ M: Randy Dunlap > >> L:linux-...@vger.kernel.org > >> T:quilt http://www.infradead.org/~rdunlap/Doc/patches/ > >> S:Maintained > >> -F:Documentation/ > >> +F:Documentation/ (but not: ABI, devicetree, translations) > > > > Maybe: > > > > X: Documentation/ABI/ > > X: Documentation/devicetree/ > > X: Documentation/[a-z][a-z]_[A-Z][A-Z]/ > > > > The last line matches: > > > > Documentation/ja_JP/ > > Documentation/ko_KR/ > > Documentation/zh_CN/ > > > > and it's easy to add any other directory you don't > > want to cc'd on. > > Thanks, I'll modify it to that syntax. > That should satisfy Josh's comment also. I'd forgotten about the existing X support. Yes, that looks perfect, thank you. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8188eu: os_dep: usb_intf.c: Fix for possible null pointer dereference
On Tue, May 20, 2014 at 06:26:51PM -0500, Larry Finger wrote: > On 05/20/2014 04:31 PM, Rickard Strandqvist wrote: > >There is otherwise a risk of a possible null pointer dereference. > > > >Was largely found by using a static code analysis program called cppcheck. > > > >Signed-off-by: Rickard Strandqvist > >--- > > drivers/staging/rtl8188eu/os_dep/usb_intf.c | 127 > > ++- > > 1 file changed, 66 insertions(+), 61 deletions(-) > > Although cppcheck's analysis is correct, pointer padapter can never > be null in any of these routines. In routine rtw_drv_init(), > rtw_usb_if1_init() is called to allocate memory for struct adapter > for the driver. If that fails, none of these other routines will > ever be called as the driver will not be loaded. > > If it is deemed better to fill the code with needless tests because > some static checker points out a place like this, that is OK with > me, but I do not see the point. If it's an invariant of the code that padapter cannot ever be NULL, then that seems perfectly fine to rely on, and the tool just needs fixing or silencing. At most, it might be helpful to add annotations like GCC's "nonnull", if that helps the checker and the compiler generate more useful warnings. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: > From: Andi Kleen > Date: Tue, 6 May 2014 05:21:14 +0200 > > > What parts would you remove to get the foot print down for a 2MB > > single purpose machine? > > I wouldn't use Linux, end of story. > > Maybe two decades ago, but not now, those days are over. That's a self-fulfilling prophecy: if you and others assume that Linux should not run on such machines, then size regressions will continue to happen, and patches to make Linux continue running on such systems will not make it into the kernel. There are real people and products intending to use Linux on incredibly tiny embedded systems; Tom already posted about one in this thread. Personally, I'd much rather see Linux on such systems rather than some crazy embedded (often proprietary) OS, and so would many other people. A NAK isn't going to cut it, here; tiny Linux systems are going to exist, and they shouldn't have to maintain a long-term out-of-tree fork or use crazy things like LWIP. I understand that you want to reduce maintenance effort and Kconfig option proliferation; that's a very real concern. It's likely possible to address those concerns while still producing a usable minimal version of the networking stack, if you'd be willing to provide feedback and support iteration of patches like these. Would you be interested in discussing this at Kernel Summit, perhaps? Would that help to hammer out a plan for this? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 08:57:03 -0700 > > > On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: > >> From: Andi Kleen > >> Date: Tue, 6 May 2014 05:21:14 +0200 > >> > >> > What parts would you remove to get the foot print down for a 2MB > >> > single purpose machine? > >> > >> I wouldn't use Linux, end of story. > >> > >> Maybe two decades ago, but not now, those days are over. > > > > That's a self-fulfilling prophecy: > > Making 2MB RAM machines today makes no sense at all. > > The lowest end dirt cheap smartphone, something which fits on > someone's pocket, has gigabytes of ram. The lowest-end smartphone isn't anywhere close to "dirt cheap", and hardly counts as "embedded" at all anymore. Smartphones cost $100+; we're talking about systems in the low tens of dollars or less. These systems will have no graphics, no peripherals, and only one or two specific functions. The entirety of their functionality will likely consist of a single userspace program; they might not even have a PID 2. *That's* the kind of "embedded" we're talking about, not the supercomputers we carry around in our pockets. Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM). Look at how much cache low-end processors have, and imagine running entirely out of *that*. Let's not surrender that entire class of devices to VxWorks, FreeRTOS, and other painfully non-Linux systems, when we already know it's possible to run Linux on them successfully. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 09:39:19AM -0700, Eric Dumazet wrote: > On Tue, 2014-05-06 at 08:57 -0700, j...@joshtriplett.org wrote: > > > A NAK isn't going to cut it, here; tiny Linux systems are going to > > exist, and they shouldn't have to maintain a long-term out-of-tree fork > > or use crazy things like LWIP. > > What's wrong with user space implementations of networking stacks ? What's wrong with the kernel implementation? > For many usages, it can bring 10 times the performance of having user > application and kernel sockets. Sounds like we have some optimization to do, then; there's no fundamental unfixable reason for that delta. > In any cases, we do not model kernel implementations to 'compete' with > user space. > > We simply can not compete with user space, as a programmer is free to > keep what he really wants/needs. The kernel can do the same. Consider the idea of analyzing a set of userspace programs, determining what kernel functionality they do and don't need, feeding that information into the kernel build process, and automatically dropping unused bits of the kernel. Ideally, that kind of process would support eliminating kernel config options that just select userspace-visible interfaces, leaving only the kernel config options that change how those interfaces behave (size/performance/feature tradeoffs). - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:17:52PM -0400, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 09:45:46 -0700 > > > The kernel can do the same. Consider the idea of analyzing a set of > > userspace programs, determining what kernel functionality they do and > > don't need, feeding that information into the kernel build process, and > > automatically dropping unused bits of the kernel. > > Please make sure I'm not on the list of people who see reports for > bugs reported in that setup. > > Thanks :-) Fine by me. Just please allow such a setup to exist. :) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 10:03:24AM -0700, Eric Dumazet wrote: > On Tue, 2014-05-06 at 09:45 -0700, j...@joshtriplett.org wrote: > > > Sounds like we have some optimization to do, then; there's no > > fundamental unfixable reason for that delta. > > I think you have little idea of the reasons for this delta. I have a rather good idea, actually. > Some servers handle 10 millions of TCP flows, using as little as 1KB per > connection in user space, all included. > > Do you have an idea of how much memory is needed for 10 millions TCP > sockets in the kernel ? Too much. That's potentially fixable, but not if we start with the premise that it's impossible. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 09:41:08 -0700 > > > Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM). > > Another poster commented that 16MB of DRAM would be cheaper than > the 2MB of ram you have on these boards, probably one that fits > your size profile is available as well. > > 2MB is just a rediculous restriction. Embedded systems experts disagree with you there; there *are* systems where the most cost-efficient approach is a few MB (or a few hundred KB) of non-discrete memory. We're not talking about socketed memory or even soldered-down memory; we're talking about entire systems that fit on a small SoC die. The space not used by that extra RAM may well be better spent on CPU optimizations, or some other integrated component. Such boards will be built, and many of them will run Linux, despite your incredulity. When you're building millions of a board, it's well worth optimizing software to eliminate components from the bill of materials. And even on a system with 4MB or 8MB or 16MB of memory, a few hundred extra KB used by the kernel and unavailable to userspace *matters*; that could be the difference between fitting in 8MB or 16MB. > And last time I checked Linux wasn't a special purpose operating > system No, it's an extremely general-purpose operating system, supporting enough customization to run on everything from supercomputers to some embedded systems. And that's partly because people who care about those systems submit patches to make Linux scale. You take patches to scale *up* to absurdly huge systems; what makes it so painful to take patches to scale *down*? > , but lucky for you I hear there are lots of those around. Why would I want to run one of those when I can run Linux? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 10:12:11AM -0700, Rick Jones wrote: > On 05/06/2014 09:41 AM, j...@joshtriplett.org wrote: > >On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: > >>Making 2MB RAM machines today makes no sense at all. > >> > >>The lowest end dirt cheap smartphone, something which fits on > >>someone's pocket, has gigabytes of ram. > > > >The lowest-end smartphone isn't anywhere close to "dirt cheap", and > >hardly counts as "embedded" at all anymore. Smartphones cost $100+; > >we're talking about systems in the low tens of dollars or less. These > >systems will have no graphics, no peripherals, and only one or two > >specific functions. The entirety of their functionality will likely > >consist of a single userspace program; they might not even have a PID 2. > >*That's* the kind of "embedded" we're talking about, not the > >supercomputers we carry around in our pockets. > > Would this be some sort of "Internet of Things" system? That's one of many buzzwords being used for this kind of system, sure. The "Internet of" part makes networking particularly important. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 11:58:38AM -0700, Tom Herbert wrote: > On Tue, May 6, 2014 at 11:32 AM, Andi Kleen wrote: > >> We simply can not compete with user space, as a programmer is free to > >> keep what he really wants/needs. > > > > Not true. > > > > With my patches and LTO Linux can be competive with LWIP+socket layer. > > (about 60K more text). And it's easier to use because it's just > > the standard interface. > > > >> I have started using linux on 386/486 pcs which had more than 2MB of > >> memory, it makes me sad we want linux-3.16 to run on this kind of > >> hardware, and consuming time to save few KB here and here. > > > > Linux has always been a system from very small to big. > > That's been one of its strengths. It is very adaptable. > > > > Many subsystems are very configurable for this. > > For example that is why we have both SLOB and SLUB. > > That is why we have NOMMU MM and lots of other tuning > > knobs for small systems. > > > > So if the other subsystems can do this, why should it be > > impossible for networking? > > > Can this at least be done without the combinatorial explosion in > number of configurations? As Yuchung pointed out these patches > introduce at least one unresolved configuration dependency. CONFIG_SMP > works quite well since with a single parameter we can enable/disable a > whole bunch of functionality in bulk, and it's quite clear that new > development cannot break smp or non-smp configurations. Maybe you want > something similar like CONFIG_NETWORK_SMALL? That seems completely reasonable. Likewise, for infrastructure that scales by CPU, keying off of CONFIG_NR_CPUS might make sense. I'd suggest inverting it, so that 'n' means "small" and 'y' means fully featured. Here's a rough description for a CONFIG_NETWORK_FULL: config NETWORK_FULL default y bool "Full-featured networking stack" if EMBEDDED --help-- Leave this option enabled for a full-featured networking stack, including features used by the vast majority of systems. Saying N here results in a minimal embedded networking stack, suitable only for the most memory-constrained and storage-constrained systems; the minimal stack removes many features, and optimizes for code and data size rather than performance. If in doubt, say Y here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:25:01PM -0400, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 10:21:06 -0700 > > > On Tue, May 06, 2014 at 01:17:52PM -0400, David Miller wrote: > >> From: j...@joshtriplett.org > >> Date: Tue, 6 May 2014 09:45:46 -0700 > >> > >> > The kernel can do the same. Consider the idea of analyzing a set of > >> > userspace programs, determining what kernel functionality they do and > >> > don't need, feeding that information into the kernel build process, and > >> > automatically dropping unused bits of the kernel. > >> > >> Please make sure I'm not on the list of people who see reports for > >> bugs reported in that setup. > >> > >> Thanks :-) > > > > Fine by me. Just please allow such a setup to exist. :) > > You see, that's the point I'm trying to make, once it's upstream > then it's my problem. > > You absolutely must consider the burdon you put upon upstream > maintainers when you ask for things to be included. Absolutely. And Andi and I are both interested in working *with* you to find a way to run on tiny embedded systems *without* necessarily introducing excessive proliferation of configuration options or unnecessarily increasing your support burden. For instance, it's easy enough to key some options off of CONFIG_NR_CPUS (such as data structure sizes), or introduce a big config switch (CONFIG_NETWORK_FULL=n or similar) that controls all of these cases rather than having option for each. That would not be hard to supply in a v2 of this patch series. And if you're asking for someone to help pay attention to bug reports so you don't have to, that's reasonable as well; just like you probably have a stock response for "that's a crazy distro kernel, ask them about it and not me", you could have a stock response for "that kernel has the crazy embedded option turned on, ask the embedded people about it and not me". It doesn't just have to be *your* problem alone. There's a stigma rightfully attached to out-of-tree patches, which roughly amounts to "people ought to submit patches upstream, we shouldn't have to support or care about out-of-tree patches". But that only works if the responses to patch submissions are either "No, because you need to fix X, Y, and Z", or "No, because your use case is better served by this existing mechanism already in the kernel", rather than "No, your use case is not valid". - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:17:58PM -0700, Eric Dumazet wrote: > On Tue, 2014-05-06 at 11:32 -0700, Andi Kleen wrote: > > > We simply can not compete with user space, as a programmer is free to > > > keep what he really wants/needs. > > > > Not true. > > You can shake the kernel as much as you want, you wont make : > - a TCP socket > - a dentry > - an inode > - a file structure > - eventpoll structures (assuming epoll use) > - 2 dst per flow. > > In 1024 bytes of memory, and keep an efficient kernel to handle > arbitrary number of sockets using the venerable and slow BSD socket api. > > I was objecting to the "crazy things like LWIP" comment from Josh, not > to your patches in general. My primary statement was that it's crazy to use something like LWIP just because you want a *tiny* system. We could argue about using LWIP because you want a massively scalable system, or one that more closely couples userspace and the kernel, but that's not the current goal in any case. So let's drop that branch of the thread. :) > I actually took a look at them but stopped at patch 22 > > Adding ~1000 lines of code to save few KB was the point I gave up. Please consider ignoring that one and reading the rest; we could always handle the routing table issue separately. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 04:44:10PM -0400, David Miller wrote: > From: Cong Wang > Date: Tue, 6 May 2014 11:33:11 -0700 > > > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? > > 2.4.x kernel doesn't have so many new features you want to get rid of here. > > +1 You've got to be kidding. Using 2.4 for a new network-connected device, today? With all of its potential security holes that nobody is paying attention to? Easier to fork 3.15 and trim it down than to do *that*. And there *are* a huge number of useful features in 3.15+, not least of which drivers for current hardware. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 05:11:17PM -0400, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 14:08:15 -0700 > > > On Tue, May 06, 2014 at 04:44:10PM -0400, David Miller wrote: > >> From: Cong Wang > >> Date: Tue, 6 May 2014 11:33:11 -0700 > >> > >> > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? > >> > 2.4.x kernel doesn't have so many new features you want to get rid of > >> > here. > >> > >> +1 > > > > You've got to be kidding. Using 2.4 for a new network-connected device, > > today? With all of its potential security holes that nobody is paying > > attention to? Easier to fork 3.15 and trim it down than to do *that*. > > And there *are* a huge number of useful features in 3.15+, not least of > > which drivers for current hardware. > > So you're saying that the 2.4.x -stable maintainer did a shitty job and > his work is worthless? There's a difference between maintaining 2.4.x for all the existing users who can't or won't upgrade, and introducing a *new* product shipping with 2.4.x. There's something very wrong if 2.4.x works for cases that 3.x doesn't; that would be a serious regression. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 01/45] rcutorture: Add forward-progress checking for writer
On Mon, Apr 28, 2014 at 05:24:49PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> The rcutorture output currently does not distinguish between stalls in
> the RCU implementation and stalls in the rcu_torture_writer() kthreads.
> This commit therefore adds some diagnostics to help distinguish between
> these two conditions, at least for the non-SRCU implementations. (SRCU
> does not provide evidence of update-side forward progress by design.)
>
> Signed-off-by: Paul E. McKenney
The concept makes sense, and the writer state annotations seem like a
useful debugging mechanism, but having RCU know about RCU torture types
seems fundamentally wrong. This mechanism accesses rcu_state, which is
already implementation-specific, so why not just only define the
function for the RCU implementations that support it, and then have a
function pointer in the torture-test structure to report a stall?
- Josh Triplett
> include/linux/rcupdate.h | 19 +++
> kernel/rcu/rcutorture.c | 37 +
> kernel/rcu/tree.c| 18 ++
> 3 files changed, 74 insertions(+)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 00a7fd61b3c6..a6c3898e141e 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -51,7 +51,17 @@ extern int rcu_expedited; /* for sysctl */
> extern int rcutorture_runnable; /* for sysctl */
> #endif /* #ifdef CONFIG_RCU_TORTURE_TEST */
>
> +enum rcutorture_type {
> + RTORT_BUSTED,
> + RTORT_RCU,
> + RTORT_RCU_BH,
> + RTORT_RCU_SCHED,
> + RTORT_SRCU
> +};
> +
> #if defined(CONFIG_TREE_RCU) || defined(CONFIG_TREE_PREEMPT_RCU)
> +void rcutorture_get_gp_data(enum rcutorture_type test_type, int *flags,
> + unsigned long *gpnum, unsigned long *completed);
> void rcutorture_record_test_transition(void);
> void rcutorture_record_progress(unsigned long vernum);
> void do_trace_rcu_torture_read(const char *rcutorturename,
> @@ -60,6 +70,15 @@ void do_trace_rcu_torture_read(const char *rcutorturename,
> unsigned long c_old,
> unsigned long c);
> #else
> +static inline void rcutorture_get_gp_data(enum rcutorture_type test_type,
> + int *flags,
> + unsigned long *gpnum,
> + unsigned long *completed)
> +{
> + *flags = 0;
> + *gpnum = 0;
> + *completed = 0;
> +}
> static inline void rcutorture_record_test_transition(void)
> {
> }
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index bd30bc61bc05..1110db210318 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -138,6 +138,15 @@ static long n_barrier_attempts;
> static long n_barrier_successes;
> static struct list_head rcu_torture_removed;
>
> +static int rcu_torture_writer_state;
> +#define RTWS_FIXED_DELAY 0
> +#define RTWS_DELAY 1
> +#define RTWS_REPLACE 2
> +#define RTWS_DEF_FREE3
> +#define RTWS_EXP_SYNC4
> +#define RTWS_STUTTER 5
> +#define RTWS_STOPPING6
> +
> #if defined(MODULE) || defined(CONFIG_RCU_TORTURE_TEST_RUNNABLE)
> #define RCUTORTURE_RUNNABLE_INIT 1
> #else
> @@ -214,6 +223,7 @@ rcu_torture_free(struct rcu_torture *p)
> */
>
> struct rcu_torture_ops {
> + int ttype;
> void (*init)(void);
> int (*readlock)(void);
> void (*read_delay)(struct torture_random_state *rrsp);
> @@ -312,6 +322,7 @@ static void rcu_sync_torture_init(void)
> }
>
> static struct rcu_torture_ops rcu_ops = {
> + .ttype = RTORT_RCU,
> .init = rcu_sync_torture_init,
> .readlock = rcu_torture_read_lock,
> .read_delay = rcu_read_delay,
> @@ -355,6 +366,7 @@ static void rcu_bh_torture_deferred_free(struct
> rcu_torture *p)
> }
>
> static struct rcu_torture_ops rcu_bh_ops = {
> + .ttype = RTORT_RCU_BH,
> .init = rcu_sync_torture_init,
> .readlock = rcu_bh_torture_read_lock,
> .read_delay = rcu_read_delay, /* just reuse rcu's version. */
> @@ -397,6 +409,7 @@ call_rcu_busted(struct rcu_head *head, void
> (*func)(struct rcu_head *rcu))
> }
>
> static struct rcu_torture_ops rcu_busted_ops = {
> + .ttype = RTORT_BUSTED,
> .init = rcu_sync_torture_init,
> .readlock = rcu_torture_read_lock,
> .read_delay = rcu_read_delay, /* just reuse rcu's version. */
>
Re: [PATCH tip/core/rcu 06/45] torture: Intensify locking test
On Mon, Apr 28, 2014 at 05:24:54PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> The current lock_torture_writer() spends too much time sleeping and not
> enough time hammering locks, as in an eight-CPU test will often only be
> utilizing a CPU or two. This commit therefore makes lock_torture_writer()
> sleep less and hammer more.
>
> Signed-off-by: Paul E. McKenney
> ---
> kernel/locking/locktorture.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> index f26b1a18e34e..b0d3e3c50672 100644
> --- a/kernel/locking/locktorture.c
> +++ b/kernel/locking/locktorture.c
> @@ -219,7 +219,8 @@ static int lock_torture_writer(void *arg)
> set_user_nice(current, 19);
>
> do {
> - schedule_timeout_uninterruptible(1);
> + if ((torture_random(&rand) & 0xf) == 0)
> + schedule_timeout_uninterruptible(1);
That's a one-in-1048576 chance of sleeping for a jiffy; is that frequent
enough to even bother sleeping at all?
> cur_ops->writelock();
> if (WARN_ON_ONCE(lock_is_write_held))
> lwsp->n_write_lock_fail++;
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 07/45] torture: Allow variations of "defconfig" to be specified
On Mon, Apr 28, 2014 at 05:24:55PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> Some environments require some variation on "make defconfig" to initialize
> the .config file. This commit therefore adds a --defconfig argument to
> allow this to be specified. The default value is of course "defconfig".
>
> Signed-off-by: Paul E. McKenney
"--defconfig randconfig" or "--defconfig allyesconfig" or similar seems
rather odd; how about calling it --kconfig or similar?
> tools/testing/selftests/rcutorture/bin/configinit.sh | 2 +-
> tools/testing/selftests/rcutorture/bin/kvm.sh| 8
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/configinit.sh
> b/tools/testing/selftests/rcutorture/bin/configinit.sh
> index a1be6e62add1..9c3f3d39b934 100755
> --- a/tools/testing/selftests/rcutorture/bin/configinit.sh
> +++ b/tools/testing/selftests/rcutorture/bin/configinit.sh
> @@ -62,7 +62,7 @@ grep '^grep' < $T/u.sh > $T/upd.sh
> echo "cat - $c" >> $T/upd.sh
> make mrproper
> make $buildloc distclean > $builddir/Make.distclean 2>&1
> -make $buildloc defconfig > $builddir/Make.defconfig.out 2>&1
> +make $buildloc $TORTURE_DEFCONFIG > $builddir/Make.defconfig.out 2>&1
> mv $builddir/.config $builddir/.config.sav
> sh $T/upd.sh < $builddir/.config.sav > $builddir/.config
> cp $builddir/.config $builddir/.config.new
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
> b/tools/testing/selftests/rcutorture/bin/kvm.sh
> index a52a077ee258..59945b7793d9 100644
> --- a/tools/testing/selftests/rcutorture/bin/kvm.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
> @@ -38,6 +38,7 @@ dur=30
> dryrun=""
> KVM="`pwd`/tools/testing/selftests/rcutorture"; export KVM
> PATH=${KVM}/bin:$PATH; export PATH
> +TORTURE_DEFCONFIG=defconfig
> TORTURE_INITRD="$KVM/initrd"; export TORTURE_INITRD
> RCU_KMAKE_ARG=""; export RCU_KMAKE_ARG
> TORTURE_SUITE=rcu
> @@ -56,6 +57,7 @@ usage () {
> echo " --configs \"config-file list\""
> echo " --cpus N"
> echo " --datestamp string"
> + echo " --defconfig string"
> echo " --dryrun sched|script"
> echo " --duration minutes"
> echo " --interactive"
> @@ -96,6 +98,11 @@ do
> ds=$2
> shift
> ;;
> + --defconfig)
> + checkarg --defconfig "defconfigtype" "$#" "$2" '^[^/][^/]*$'
> '^--'
> + TORTURE_DEFCONFIG=$2
> + shift
> + ;;
> --dryrun)
> checkarg --dryrun "sched|script" $# "$2" 'sched\|script' '^--'
> dryrun=$2
> @@ -259,6 +266,7 @@ END {
> # Generate a script to execute the tests in appropriate batches.
> cat << ___EOF___ > $T/script
> TORTURE_SUITE="$TORTURE_SUITE"; export TORTURE_SUITE
> +TORTURE_DEFCONFIG="$TORTURE_DEFCONFIG"; export TORTURE_DEFCONFIG
> ___EOF___
> awk < $T/cfgcpu.pack \
> -v CONFIGDIR="$CONFIGFRAG/$kversion/" \
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 08/45] torture: Rename RCU_KMAKE_ARG to TORTURE_KMAKE_ARG
On Mon, Apr 28, 2014 at 05:24:56PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit makes the torture scripts a bit more RCU-independent.
You've also dropped unnecessary "export" calls; please document that in
the commit message. With that change:
> Signed-off-by: Paul E. McKenney
Reviewed-by: Josh Triplett
> ---
> tools/testing/selftests/rcutorture/bin/kvm-build.sh | 2 +-
> tools/testing/selftests/rcutorture/bin/kvm.sh | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-build.sh
> b/tools/testing/selftests/rcutorture/bin/kvm-build.sh
> index d8e68a5e4411..e838c775f709 100755
> --- a/tools/testing/selftests/rcutorture/bin/kvm-build.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm-build.sh
> @@ -60,7 +60,7 @@ then
> exit 2
> fi
> ncpus=`cpus2use.sh`
> -make O=$builddir -j$ncpus $RCU_KMAKE_ARG > $builddir/Make.out 2>&1
> +make O=$builddir -j$ncpus $TORTURE_KMAKE_ARG > $builddir/Make.out 2>&1
> retval=$?
> if test $retval -ne 0 || grep "rcu[^/]*": < $builddir/Make.out | egrep -q
> "Stop|Error|error:|warning:" || egrep -q "Stop|Error|error:" <
> $builddir/Make.out
> then
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
> b/tools/testing/selftests/rcutorture/bin/kvm.sh
> index 59945b7793d9..04ad1f980dfe 100644
> --- a/tools/testing/selftests/rcutorture/bin/kvm.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
> @@ -40,7 +40,7 @@ KVM="`pwd`/tools/testing/selftests/rcutorture"; export KVM
> PATH=${KVM}/bin:$PATH; export PATH
> TORTURE_DEFCONFIG=defconfig
> TORTURE_INITRD="$KVM/initrd"; export TORTURE_INITRD
> -RCU_KMAKE_ARG=""; export RCU_KMAKE_ARG
> +TORTURE_KMAKE_ARG=""
> TORTURE_SUITE=rcu
> resdir=""
> configs=""
> @@ -118,7 +118,7 @@ do
> ;;
> --kmake-arg)
> checkarg --kmake-arg "(kernel make arguments)" $# "$2" '.*'
> '^error$'
> - RCU_KMAKE_ARG="$2"; export RCU_KMAKE_ARG
> + TORTURE_KMAKE_ARG="$2"
> shift
> ;;
> --kversion)
> @@ -376,7 +376,7 @@ then
> echo PATH="$PATH; export PATH"
> echo RCU_BUILDONLY="$RCU_BUILDONLY; export RCU_BUILDONLY"
> echo TORTURE_INITRD="$TORTURE_INITRD; export TORTURE_INITRD"
> - echo RCU_KMAKE_ARG="$RCU_KMAKE_ARG; export RCU_KMAKE_ARG"
> + echo TORTURE_KMAKE_ARG="$TORTURE_KMAKE_ARG; export TORTURE_KMAKE_ARG"
> echo RCU_QEMU_CMD="$RCU_QEMU_CMD; export RCU_QEMU_CMD"
> echo RCU_QEMU_INTERACTIVE="$RCU_QEMU_INTERACTIVE; export
> RCU_QEMU_INTERACTIVE"
> echo RCU_QEMU_MAC="$RCU_QEMU_MAC; export RCU_QEMU_MAC"
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 10/45] torture: Rename RCU_BUILDONLY to TORTURE_BUILDONLY
On Mon, Apr 28, 2014 at 05:24:58PM -0700, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > This commit makes the torture scripts a bit more RCU-independent. And removes unnecessary exports; please document that. With that change: > Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett > --- > tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 2 +- > tools/testing/selftests/rcutorture/bin/kvm.sh| 9 ++--- > 2 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh > b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh > index e82f4f201c8c..86e6ffe6df45 100755 > --- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh > +++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh > @@ -152,7 +152,7 @@ boot_args="`configfrag_boot_params "$boot_args" > "$config_template"`" > boot_args="`per_version_boot_params "$boot_args" $builddir/.config $seconds`" > > echo $QEMU $qemu_args -m 512 -kernel $builddir/arch/x86/boot/bzImage -append > \"$qemu_append $boot_args\" > $resdir/qemu-cmd > -if test -n "$RCU_BUILDONLY" > +if test -n "$TORTURE_BUILDONLY" > then > echo Build-only run specified, boot/test omitted. > exit 0 > diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh > b/tools/testing/selftests/rcutorture/bin/kvm.sh > index 08c90cba79d2..73c586f6bdf6 100644 > --- a/tools/testing/selftests/rcutorture/bin/kvm.sh > +++ b/tools/testing/selftests/rcutorture/bin/kvm.sh > @@ -81,7 +81,7 @@ do > shift > ;; > --buildonly) > - RCU_BUILDONLY=1; export RCU_BUILDONLY > + TORTURE_BUILDONLY=1 > ;; > --configs) > checkarg --configs "(list of config files)" "$#" "$2" '^[^/]*$' > '^--' > @@ -374,7 +374,7 @@ then > echo KVM="$KVM; export KVM" > echo KVPATH="$KVPATH; export KVPATH" > echo PATH="$PATH; export PATH" > - echo RCU_BUILDONLY="$RCU_BUILDONLY; export RCU_BUILDONLY" > + echo TORTURE_BUILDONLY="$TORTURE_BUILDONLY; export TORTURE_BUILDONLY" > echo TORTURE_INITRD="$TORTURE_INITRD; export TORTURE_INITRD" > echo TORTURE_KMAKE_ARG="$TORTURE_KMAKE_ARG; export TORTURE_KMAKE_ARG" > echo RCU_QEMU_CMD="$RCU_QEMU_CMD; export RCU_QEMU_CMD" > @@ -402,4 +402,7 @@ echo > echo > echo " --- `date` Test summary:" > echo Results directory: $resdir/$ds > -kvm-recheck.sh $resdir/$ds > +if test -n "$TORTURE_BUILDONLY" > +then > + kvm-recheck.sh $resdir/$ds > +fi > -- > 1.8.1.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 11/45] torture: Rename RCU_QEMU_INTERACTIVE to TORTURE_QEMU_INTERACTIVE
On Mon, Apr 28, 2014 at 05:24:59PM -0700, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > This commit makes the torture scripts a bit more RCU-independent. > > Signed-off-by: Paul E. McKenney Bug below; with that fixed, Reviewed-by: Josh Triplett > --- a/tools/testing/selftests/rcutorture/bin/kvm.sh > +++ b/tools/testing/selftests/rcutorture/bin/kvm.sh [...] > @@ -378,7 +378,8 @@ then > echo TORTURE_INITRD="$TORTURE_INITRD; export TORTURE_INITRD" > echo TORTURE_KMAKE_ARG="$TORTURE_KMAKE_ARG; export TORTURE_KMAKE_ARG" > echo RCU_QEMU_CMD="$RCU_QEMU_CMD; export RCU_QEMU_CMD" > - echo RCU_QEMU_INTERACTIVE="$RCU_QEMU_INTERACTIVE; export > RCU_QEMU_INTERACTIVE" > + echo TORTURE_QEMU_INTERACTIVE="$TORTURE_QEMU_INTERACTIVE; > + export TORTURE_QEMU_INTERACTIVE" Don't break this line in the middle of your quoted string. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 11/45] torture: Rename RCU_QEMU_INTERACTIVE to TORTURE_QEMU_INTERACTIVE
On Mon, Apr 28, 2014 at 05:24:59PM -0700, Paul E. McKenney wrote: > - if test -n "$RCU_QEMU_INTERACTIVE" -a -n "$RCU_QEMU_MAC" > + if test -n "$TORTURE_QEMU_INTERACTIVE" -a -n "$RCU_QEMU_MAC" > then > echo -device spapr-vlan,netdev=net0,mac=$RCU_QEMU_MAC > echo -netdev bridge,br=br0,id=net0 > - elif test -n "$RCU_QEMU_INTERACTIVE" > + elif test -n "$TORTURE_QEMU_INTERACTIVE" > then > echo -net nic -net user Not related to this patch, but: qemu defaults to -net nic -net user, so you don't need to specify it. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 12/45] torture: Rename RCU_QEMU_MAC to TORTURE_QEMU_MAC
On Mon, Apr 28, 2014 at 05:25:00PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit makes the torture scripts a bit more RCU-independent.
>
> Signed-off-by: Paul E. McKenney
One comment below; with or without that change:
Reviewed-by: Josh Triplett
> ---
> tools/testing/selftests/rcutorture/bin/functions.sh | 6 +++---
> tools/testing/selftests/rcutorture/bin/kvm.sh | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh
> b/tools/testing/selftests/rcutorture/bin/functions.sh
> index 623939cf814e..41fb52b805e4 100644
> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
> @@ -124,7 +124,7 @@ identify_qemu_append () {
>
> # identify_qemu_args qemu-cmd serial-file
> #
> -# Output arguments for qemu arguments based on the RCU_QEMU_MAC
> +# Output arguments for qemu arguments based on the TORTURE_QEMU_MAC
> # and TORTURE_QEMU_INTERACTIVE environment variables.
> identify_qemu_args () {
> case "$1" in
> @@ -133,9 +133,9 @@ identify_qemu_args () {
> qemu-system-ppc64)
> echo -enable-kvm -M pseries -cpu POWER7 -nodefaults
> echo -device spapr-vscsi
> - if test -n "$TORTURE_QEMU_INTERACTIVE" -a -n "$RCU_QEMU_MAC"
> + if test -n "$TORTURE_QEMU_INTERACTIVE" -a -n "$TORTURE_QEMU_MAC"
> then
> - echo -device spapr-vlan,netdev=net0,mac=$RCU_QEMU_MAC
> + echo -device
> spapr-vlan,netdev=net0,mac=$TORTURE_QEMU_MAC
> echo -netdev bridge,br=br0,id=net0
> elif test -n "$TORTURE_QEMU_INTERACTIVE"
> then
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
> b/tools/testing/selftests/rcutorture/bin/kvm.sh
> index 2f9605ed5b58..1a4a68c76914 100644
> --- a/tools/testing/selftests/rcutorture/bin/kvm.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
> @@ -128,7 +128,7 @@ do
> ;;
> --mac)
> checkarg --mac "(MAC address)" $# "$2"
> '^\([0-9a-fA-F]\{2\}:\)\{5\}[0-9a-fA-F]\{2\}$' error
> - RCU_QEMU_MAC=$2; export RCU_QEMU_MAC
> + TORTURE_QEMU_MAC=$2; export TORTURE_QEMU_MAC
Can't you drop this export the same way you did previous exports?
> shift
> ;;
> --no-initrd)
> @@ -380,7 +380,7 @@ then
> echo RCU_QEMU_CMD="$RCU_QEMU_CMD; export RCU_QEMU_CMD"
> echo TORTURE_QEMU_INTERACTIVE="$TORTURE_QEMU_INTERACTIVE;
> export TORTURE_QEMU_INTERACTIVE"
> - echo RCU_QEMU_MAC="$RCU_QEMU_MAC; export RCU_QEMU_MAC"
> + echo TORTURE_QEMU_MAC="$TORTURE_QEMU_MAC; export TORTURE_QEMU_MAC"
> echo "mkdir -p "$resdir" || :"
> echo "mkdir $resdir/$ds"
> cat $T/script
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 15/45] torture: Make config-fragment filtering RCU-independent
On Mon, Apr 28, 2014 at 05:25:03PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> The torture tests need to set specific values for their respective
> Kconfig options (e.g., CONFIG_LOCK_TORTURE_TEST), and must therefore
> filter any conflicting definitions from the Kconfig fragment
> file. Unfortunately, the code in kvm-build.sh was looking only for
> CONFIG_RCU_TORTURE_TEST. This commit therefore handles the general case
> of CONFIG_[A-Z]*TORTURE_TEST.
This doesn't match your code below, which includes an _ after the * .
Also, one nit below.
> Signed-off-by: Paul E. McKenney
With the commit message fixed:
Reviewed-by: Josh Triplett
> ---
> tools/testing/selftests/rcutorture/bin/kvm-build.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-build.sh
> b/tools/testing/selftests/rcutorture/bin/kvm-build.sh
> index e838c775f709..6d0b76d918f4 100755
> --- a/tools/testing/selftests/rcutorture/bin/kvm-build.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm-build.sh
> @@ -45,7 +45,7 @@ T=/tmp/test-linux.sh.$$
> trap 'rm -rf $T' 0
> mkdir $T
>
> -cat ${config_template} | grep -v CONFIG_RCU_TORTURE_TEST > $T/config
> +cat ${config_template} | grep -v 'CONFIG_[A-Z]*_TORTURE_TEST' > $T/config
UUOC (useless use of cat): you can redirect from ${config_template}
rather than catting it.
> cat << ___EOF___ >> $T/config
> CONFIG_INITRAMFS_SOURCE="$TORTURE_INITRD"
> CONFIG_VIRTIO_PCI=y
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 18/45] torture: Make "--dryrun script" use same environment as normal run
On Mon, Apr 28, 2014 at 05:25:06PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> In a normal torture-test run, the script inherits its environment
> variables, but this does not work when producing a script that is
> to run later. Therefore, definitions and exports are prepended to
> a dryrun script but not to a script that is run immediately. This
> commit reconciles this by placing definitions and exports at the
> beginning of the script in both cases.
Cleanup idea, not needed in this commit: This has gotten sufficiently
long to warrant a loop over a list of environment variables, or possibly
a loop over all environment variable starting with TORTURE_* .
> Signed-off-by: Paul E. McKenney
Reviewed-by: Josh Triplett
> ---
> tools/testing/selftests/rcutorture/bin/kvm.sh | 28
> ---
> 1 file changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
> b/tools/testing/selftests/rcutorture/bin/kvm.sh
> index 8aa62a2dccb5..93a6c5a8517d 100644
> --- a/tools/testing/selftests/rcutorture/bin/kvm.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
> @@ -241,8 +241,19 @@ END {
>
> # Generate a script to execute the tests in appropriate batches.
> cat << ___EOF___ > $T/script
> -TORTURE_SUITE="$TORTURE_SUITE"; export TORTURE_SUITE
> +CONFIGFRAG="$CONFIGFRAG"; export CONFIGFRAG
> +KVM="$KVM"; export KVM
> +KVPATH="$KVPATH"; export KVPATH
> +PATH="$PATH"; export PATH
> +TORTURE_BUILDONLY="$TORTURE_BUILDONLY"; export TORTURE_BUILDONLY
> TORTURE_DEFCONFIG="$TORTURE_DEFCONFIG"; export TORTURE_DEFCONFIG
> +TORTURE_INITRD="$TORTURE_INITRD"; export TORTURE_INITRD
> +TORTURE_KMAKE_ARG="$TORTURE_KMAKE_ARG"; export TORTURE_KMAKE_ARG
> +TORTURE_QEMU_CMD="$TORTURE_QEMU_CMD"; export TORTURE_QEMU_CMD
> +TORTURE_QEMU_INTERACTIVE="$TORTURE_QEMU_INTERACTIVE";
> + export TORTURE_QEMU_INTERACTIVE
> +TORTURE_QEMU_MAC="$TORTURE_QEMU_MAC"; export TORTURE_QEMU_MAC
> +TORTURE_SUITE="$TORTURE_SUITE"; export TORTURE_SUITE
> if ! test -e $resdir
> then
> mkdir -p "$resdir" || :
> @@ -371,21 +382,6 @@ ___EOF___
>
> if test "$dryrun" = script
> then
> - # Dump out the script, but define the environment variables that
> - # it needs to run standalone.
> - echo CONFIGFRAG="$CONFIGFRAG; export CONFIGFRAG"
> - echo KVM="$KVM; export KVM"
> - echo KVPATH="$KVPATH; export KVPATH"
> - echo PATH="$PATH; export PATH"
> - echo TORTURE_BUILDONLY="$TORTURE_BUILDONLY; export TORTURE_BUILDONLY"
> - echo TORTURE_INITRD="$TORTURE_INITRD; export TORTURE_INITRD"
> - echo TORTURE_KMAKE_ARG="$TORTURE_KMAKE_ARG; export TORTURE_KMAKE_ARG"
> - echo TORTURE_QEMU_CMD="$TORTURE_QEMU_CMD; export TORTURE_QEMU_CMD"
> - echo TORTURE_QEMU_INTERACTIVE="$TORTURE_QEMU_INTERACTIVE;
> - export TORTURE_QEMU_INTERACTIVE"
> - echo TORTURE_QEMU_MAC="$TORTURE_QEMU_MAC; export TORTURE_QEMU_MAC"
> - echo "mkdir -p "$resdir" || :"
> - echo "mkdir $resdir/$ds"
> cat $T/script
> exit 0
> elif test "$dryrun" = sched
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 19/45] rcutorture: Print negatives for SRCU counter wraparound
On Mon, Apr 28, 2014 at 05:25:07PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> The srcu_torture_stats() function prints SRCU's per-CPU c[] array with
> an unsigned format, which means that the number one less than zero is
> a very large number. This commit therefore prints this array with a
> signed format in order to improve readability of the rcutorture output.
>
> Signed-off-by: Paul E. McKenney
Nit below; with that:
Reviewed-by: Josh Triplett
> kernel/rcu/rcutorture.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index 3845ea99ccd4..0141fcff6bb9 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -486,15 +486,16 @@ static void srcu_torture_barrier(void)
>
> static void srcu_torture_stats(char *page)
> {
> + long c0, c1;
> int cpu;
> int idx = srcu_ctl.completed & 0x1;
>
> page += sprintf(page, "%s%s per-CPU(idx=%d):",
> torture_type, TORTURE_FLAG, idx);
> for_each_possible_cpu(cpu) {
> - page += sprintf(page, " %d(%lu,%lu)", cpu,
> -per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[!idx],
> -per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[idx]);
> + c0 = (long)per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[!idx];
> + c1 = (long)per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[idx];
> + page += sprintf(page, " %d(%ld,%ld)", cpu, c0, c1);
Nit: I'd suggest declaring the variables inside the loop, or not using
intermediate variables at all.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 20/45] torture: Include "Stopping" string to torture_kthread_stopping()
On Mon, Apr 28, 2014 at 05:25:08PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> Currently, torture_kthread_stopping() prints only the name of the
> kthread that is stopping, which can be unedifying. This commit therefore
> adds "Stopping" to make things more evident.
>
> Signed-off-by: Paul E. McKenney
Feedback below.
> kernel/torture.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/torture.c b/kernel/torture.c
> index acc9afc2f26e..f329848c3eee 100644
> --- a/kernel/torture.c
> +++ b/kernel/torture.c
> @@ -674,8 +674,11 @@ EXPORT_SYMBOL_GPL(torture_must_stop_irq);
> */
> void torture_kthread_stopping(char *title)
> {
> + char buf[128];
> +
> + snprintf(buf, sizeof(buf), "Stopping %s", title);
> if (verbose)
> - VERBOSE_TOROUT_STRING(title);
> + VERBOSE_TOROUT_STRING(buf);
This seems like a case where the macro has led to poorer code; rather
than using sprintf into a temporary buffer, this should just print.
Please consider fixing the output macros to allow formats, as the pr_*
macros do.
Also, why do you need "if (verbose)" if the name of the macro has
VERBOSE_ in it; shouldn't that mean it checks verbosity itself?
(Another good reason not to create a unique verbosity level mechanism,
and to use the kernel mechanisms instead.)
> while (!kthread_should_stop()) {
> torture_shutdown_absorb(title);
> schedule_timeout_uninterruptible(1);
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 21/45] torture: Report diagnostics from qemu
On Mon, Apr 28, 2014 at 05:25:09PM -0700, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > The current script does record qemu diagnostics, but the user has to > know where to look for them. This commit therefore puts them into the > Warnings file so that kvm-recheck.sh will display them. This change is > especially useful if you are in the habit of killing the qemu process > when you realize that you messed something up, but then later on wonder > why the process terminated early. > > Signed-off-by: Paul E. McKenney A couple of issues below. > @@ -172,6 +172,14 @@ do > if test $kruntime -lt $seconds > then > echo Completed in $kruntime vs. $seconds >> > $resdir/Warnings 2>&1 > + grep "^(qemu) qemu:" $resdir/kvm-test-1-run.sh.out >> > $resdir/Warnings 2>&1 > + killpid="`grep "^(qemu) qemu: terminating on signal > [0-9]* from pid" $resdir/kvm-test-1-run.sh.out`" You already searched for lines like this and put them in Warnings in the previous line, so you don't need to search the entire output. Also, you use grep here and sed below; you could just use sed here to directly obtain the PID: killpid="$(sed -n "s/^(qemu) qemu: terminating on signal [0-9]* from pid \([0-9]*\).*$/\1/p" $resdir/Warnings)" > + if test -n "$killpid" > + then > + pscmd="`echo $killpid | sed -e 's/^.*from > pid/ps -ef | grep/'`" > + echo $pscmd >> $resdir/Warnings > + echo $pscmd | sh >> $resdir/Warnings 2>&1 > + fi Grepping for a PID is a bad idea; it'll turn up anything that contains that PID anywhere on the line, including as a substring. Given the above change to obtain a numeric $killpid, you can instead pass the PID to ps directly: if test -n "$killpid" then ps -fp $killpid >> $resdir/Warnings 2>&1 fi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 24/45] torture: Choose bzImage location based on architecture
On Mon, Apr 28, 2014 at 05:25:12PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> Currently, the scripts hard-code arch/x86/boot/bzImage, which does not
> work well for other architectures. This commit therefore provides a
> identify_boot_image function that selects the correct bzImage location
> relative to the top of the Linux source tree. This commit also adds a
> --bootimage argument that allows selecting some other file, for example,
> "vmlinux".
>
> Signed-off-by: Paul E. McKenney
Two issues below; with those fixed,
Reviewed-by: Josh Triplett
> tools/testing/selftests/rcutorture/bin/functions.sh | 21
> +
> .../selftests/rcutorture/bin/kvm-test-1-run.sh | 11 +--
> tools/testing/selftests/rcutorture/bin/kvm.sh | 8
> 3 files changed, 34 insertions(+), 6 deletions(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh
> b/tools/testing/selftests/rcutorture/bin/functions.sh
> index 6b2adb29b073..efa95867e1cc 100644
> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
> @@ -76,6 +76,27 @@ configfrag_hotplug_cpu () {
> grep -q '^CONFIG_HOTPLUG_CPU=y$' "$1"
> }
>
> +# identify_boot_image qemu-cmd
> +#
> +# Returns the relative path to the kernel build image. This will be
> +# arch//boot/bzImage unless overridden with the TORTURE_BOOT_IMAGE
> +# environment variable.
> +identify_boot_image () {
> + if test -n "$TORTURE_BOOT_IMAGE"
> + then
> + echo $TORTURE_BOOT_IMAGE
> + else
> + case "$1" in
> + qemu-system-x86_64|qemu-system-i386)
> + echo arch/x86/boot/bzImage
> + ;;
> + qemu-system-ppc64)
> + echo arch/powerpc/boot/bzImage
> + ;;
*)
(fail noisily rather than silently)
> + esac
> + fi
> +}
> +
> # identify_qemu builddir
> #
> # Returns our best guess as to which qemu command is appropriate for
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> index 7848227aa4c1..7a95f86cc85a 100755
> --- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> @@ -94,9 +94,11 @@ fi
> # CONFIG_YENTA=n
> if kvm-build.sh $config_template $builddir $T
> then
> + QEMU="`identify_qemu $builddir/vmlinux`"
> + BOOT_IMAGE="`identify_boot_image $QEMU`"
> cp $builddir/Make*.out $resdir
> cp $builddir/.config $resdir
> - cp $builddir/arch/x86/boot/bzImage $resdir
> + cp $builddir/$BOOT_IMAGE $resdir
> parse-build.sh $resdir/Make.out $title
> if test -f $builddir.wait
> then
> @@ -124,9 +126,6 @@ cd $KVM
> kstarttime=`awk 'BEGIN { print systime() }' < /dev/null`
> echo ' ---' `date`: Starting kernel
>
> -# Determine the appropriate flavor of qemu command.
> -QEMU="`identify_qemu $builddir/vmlinux`"
> -
This change seems related but undocumented.
> # Generate -smp qemu argument.
> qemu_args="-nographic $qemu_args"
> cpu_count=`configNR_CPUS.sh $config_template`
> @@ -151,13 +150,13 @@ boot_args="`configfrag_boot_params "$boot_args"
> "$config_template"`"
> # Generate kernel-version-specific boot parameters
> boot_args="`per_version_boot_params "$boot_args" $builddir/.config $seconds`"
>
> -echo $QEMU $qemu_args -m 512 -kernel $builddir/arch/x86/boot/bzImage -append
> \"$qemu_append $boot_args\" > $resdir/qemu-cmd
> +echo $QEMU $qemu_args -m 512 -kernel $builddir/$BOOT_IMAGE -append
> \"$qemu_append $boot_args\" > $resdir/qemu-cmd
> if test -n "$TORTURE_BUILDONLY"
> then
> echo Build-only run specified, boot/test omitted.
> exit 0
> fi
> -$QEMU $qemu_args -m 512 -kernel $builddir/arch/x86/boot/bzImage -append
> "$qemu_append $boot_args"; echo $? > $resdir/qemu-retval &
> +$QEMU $qemu_args -m 512 -kernel $builddir/$BOOT_IMAGE -append "$qemu_append
> $boot_args"; echo $? > $resdir/qemu-retval &
> qemu_pid=$!
> commandcompleted=0
> echo Monitoring qemu job at pid $qemu_pid
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
> b/tools/testing/selftests/rcutorture/bin/kvm.sh
> index 9b838c372698..4eed2a4f42c7 100644
> --- a/tools/testing/selftests/rcutorture/bin/kvm.sh
> +++ b/tools/testing/selftests/rcutorture/b
Re: [PATCH tip/core/rcu 27/45] rcutorture: Export RCU grace-period kthread wait state to rcutorture
On Mon, Apr 28, 2014 at 05:25:15PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit allows rcutorture to print additional state for the
> RCU grace-period kthreads in cases where RCU seems reluctant to
> start a new grace period.
>
> Signed-off-by: Paul E. McKenney
Should something reset gp_state after fqs finishes?
Reviewed-by: Josh Triplett
> include/linux/rcutiny.h | 4
> include/linux/rcutree.h | 1 +
> kernel/rcu/rcutorture.c | 1 +
> kernel/rcu/tree.c | 17 +
> kernel/rcu/tree.h | 8 +++-
> 5 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> index 425c659d54e5..d40a6a451330 100644
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -119,6 +119,10 @@ static inline void rcu_sched_force_quiescent_state(void)
> {
> }
>
> +static inline void show_rcu_gp_kthreads(void)
> +{
> +}
> +
> static inline void rcu_cpu_stall_reset(void)
> {
> }
> diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
> index a59ca05fd4e3..3e2f5d432743 100644
> --- a/include/linux/rcutree.h
> +++ b/include/linux/rcutree.h
> @@ -84,6 +84,7 @@ extern unsigned long rcutorture_vernum;
> long rcu_batches_completed(void);
> long rcu_batches_completed_bh(void);
> long rcu_batches_completed_sched(void);
> +void show_rcu_gp_kthreads(void);
>
> void rcu_force_quiescent_state(void);
> void rcu_bh_force_quiescent_state(void);
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index 50c26a7b6d97..15af04177e7e 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -1033,6 +1033,7 @@ rcu_torture_printk(char *page)
> "??? Writer stall state %d g%lu c%lu f%#x\n",
> rcu_torture_writer_state,
> gpnum, completed, flags);
> + show_rcu_gp_kthreads();
> rcutorture_trace_dump();
> }
> rtcv_snap = rcu_torture_current_version;
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 032106df7391..3107bd935b2b 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -280,6 +280,21 @@ void rcu_bh_force_quiescent_state(void)
> EXPORT_SYMBOL_GPL(rcu_bh_force_quiescent_state);
>
> /*
> + * Show the state of the grace-period kthreads.
> + */
> +void show_rcu_gp_kthreads(void)
> +{
> + struct rcu_state *rsp;
> +
> + for_each_rcu_flavor(rsp) {
> + pr_info("%s: wait state: %d ->state: %#lx\n",
> + rsp->name, rsp->gp_state, rsp->gp_kthread->state);
> + /* sched_show_task(rsp->gp_kthread); */
> + }
> +}
> +EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads);
> +
> +/*
> * Record the number of times rcutorture tests have been initiated and
> * terminated. This information allows the debugfs tracing stats to be
> * correlated to the rcutorture messages, even when the rcutorture module
> @@ -1611,6 +1626,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
> trace_rcu_grace_period(rsp->name,
> ACCESS_ONCE(rsp->gpnum),
> TPS("reqwait"));
> + rsp->gp_state = RCU_GP_WAIT_GPS;
> wait_event_interruptible(rsp->gp_wq,
>ACCESS_ONCE(rsp->gp_flags) &
>RCU_GP_FLAG_INIT);
> @@ -1638,6 +1654,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
> trace_rcu_grace_period(rsp->name,
> ACCESS_ONCE(rsp->gpnum),
> TPS("fqswait"));
> + rsp->gp_state = RCU_GP_WAIT_FQS;
> ret = wait_event_interruptible_timeout(rsp->gp_wq,
> ((gf = ACCESS_ONCE(rsp->gp_flags)) &
>RCU_GP_FLAG_FQS) ||
> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> index 75dc3c39a02a..c2fd1e722879 100644
> --- a/kernel/rcu/tree.h
> +++ b/kernel/rcu/tree.h
> @@ -406,7 +406,8 @@ struct rcu_state {
> unsigned long completed;/* # of last completed gp. */
> struct task_struct *gp_kthread; /* Task for grace periods. */
> wait_queue_head_t gp_wq;/* Where GP task waits. */
> - int gp_flags; /* Commands for GP task. */
> + short gp_flags;
Re: [PATCH tip/core/rcu 32/45] torture: Better summary diagnostics for build failures
On Mon, Apr 28, 2014 at 05:25:20PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> The reaction of kvm-recheck.sh is obscure at best, and easy to miss
> completely. This commit therefore prints "BUG: Build failed" in the
> summary at the end of a run.
This commit also changes a dozen other things about the output that this
commit message does not document. :)
> Signed-off-by: Paul E. McKenney
> ---
> .../selftests/rcutorture/bin/kvm-recheck-lock.sh | 2 +-
> .../selftests/rcutorture/bin/kvm-recheck-rcu.sh| 2 +-
> .../selftests/rcutorture/bin/kvm-recheck.sh| 24
> --
> .../selftests/rcutorture/bin/kvm-test-1-run.sh | 1 +
> 4 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh
> b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh
> index 829186e19eb1..7f1ff1a8fc4b 100755
> --- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh
> @@ -35,7 +35,7 @@ configfile=`echo $i | sed -e 's/^.*\///'`
> ncs=`grep "Writes: Total:" $i/console.log 2> /dev/null | tail -1 | sed -e
> 's/^.* Total: //' -e 's/ .*$//'`
> if test -z "$ncs"
> then
> - echo $configfile
> + echo "$configfile ---"
> else
> title="$configfile --- $ncs acquisitions/releases"
> dur=`sed -e 's/^.* locktorture.shutdown_secs=//' -e 's/ .*$//' <
> $i/qemu-cmd 2> /dev/null`
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
> b/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
> index d75b1dc5ae53..307c4b95f325 100755
> --- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
> @@ -35,7 +35,7 @@ configfile=`echo $i | sed -e 's/^.*\///'`
> ngps=`grep ver: $i/console.log 2> /dev/null | tail -1 | sed -e 's/^.* ver:
> //' -e 's/ .*$//'`
> if test -z "$ngps"
> then
> - echo $configfile
> + echo "$configfile ---"
> else
> title="$configfile --- $ngps grace periods"
> dur=`sed -e 's/^.* rcutorture.shutdown_secs=//' -e 's/ .*$//' <
> $i/qemu-cmd 2> /dev/null`
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh
> b/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh
> index 26d78b7eaccf..ee1f6cae3d70 100755
> --- a/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh
> @@ -25,6 +25,7 @@
> # Authors: Paul E. McKenney
>
> PATH=`pwd`/tools/testing/selftests/rcutorture/bin:$PATH; export PATH
> +. tools/testing/selftests/rcutorture/bin/functions.sh
> for rd in "$@"
> do
> firsttime=1
> @@ -39,13 +40,24 @@ do
> fi
> TORTURE_SUITE="`cat $i/../TORTURE_SUITE`"
> kvm-recheck-${TORTURE_SUITE}.sh $i
> - configcheck.sh $i/.config $i/ConfigFragment
> - parse-build.sh $i/Make.out $configfile
> - parse-torture.sh $i/console.log $configfile
> - parse-console.sh $i/console.log $configfile
> - if test -r $i/Warnings
> + if test -f "$i/console.log"
> then
> - cat $i/Warnings
> + configcheck.sh $i/.config $i/ConfigFragment
> + parse-build.sh $i/Make.out $configfile
> + parse-torture.sh $i/console.log $configfile
> + parse-console.sh $i/console.log $configfile
> + if test -r $i/Warnings
> + then
> + cat $i/Warnings
> + fi
> + else
> + if test -f "$i/qemu-cmd"
> + then
> + print_bug qemu failed
> + else
> + print_bug Build failed
> + fi
> + echo " $i"
> fi
> done
> done
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> index 7a95f86cc85a..51c34a91a375 100755
> --- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> @@ -106,6 +106,7 @@ then
> fi
> else
> cp $builddir/Make*.out $resdir
> + cp $builddir/.config $resdir || :
> echo Build failed, not running KVM, see $resdir.
> if test -f $builddir.wait
> then
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
