Re: problem in building 4.8.0: references to non-existent util CLANG
Randy Dunlap wrote: On 08/18/2018 05:48 PM, Linda Walsh wrote: Is CLANG required for building now? Looks like this patch should fix it: https://marc.info/?l=linux-kbuild&m=153447099313149&w=2 --- Thanks much!
Re: RFC: Revert move default dialect from CIFS to to SMB3
Linus Torvalds wrote: On Thu, Aug 31, 2017 at 2:36 PM, Thorsten Leemhuis wrote: Lo! To give a bit more background to this (the mail I reply to was the first I sent with git send-email and I missed some details): Maybe I'm over stretching my abilities/position as regression tracker with this RFC for a revert, but I hope it at least triggers a discussion if such a revert should be done or not. I don't think that a revert is appropriate. But perhaps just a single printk() or something if the user does *not* specify the version explicitly? Just saying something like We used to default to 1.0, we now default to 3.0, if you want old defaults, use "vers=1.0" Why be incompatible with the majority of Windows installations? I.e. If you really want to up security from 1.0 (not adverse to that), then why not go to 2.1 as used by Win7? Win7 is still in support from MS -- and they haven't indicated a need to upgrade to 3.x for security reasons. 3.x may have new security features, no argument, but that doesn't mean 2.1, is insecure. I do *not* believe that "default to version 1" is acceptable. --- But does it have to jump to 3? I.e. Why not go a more middle route of 2.1 -- as it is still security-supported by MS. Ideally MS would find some bug in 2.1 and allow 3.x to be an upgrade to Win7, but until then... Linda
Re: RFC: Revert move default dialect from CIFS to to SMB3"
Thorsten Leemhuis wrote: This reverts commit eef914a9eb5eb83e60eb498315a491cd1edc13a1 ( [SMB3] Improve security, move default dialect to SMB3 from old CIFS), as it confuses users: https://bugzilla.kernel.org/show_bug.cgi?id=196599 It was a patch to improve security by switching to SMB3 by default and support SMB1 (aka CIFS) only when explicitly requested, as the latter is not considered secure anymore (see below for details). This is one of the rare cases where regressions are unavoidable and accepted in Linux. Why not SMB2.1? Win7 is still in support and getting security updates. MS has not issued any updates for Win7 upgrading it to SMB3.0 for any reason (that I'm aware of) -- including security. If there were security problems in Win7 w/SMB2.1, wouldn't MS issue patches -- as they did for WinXP just recently for a severe SMB1 bug? Seems like if they are willing to patch "out of support" XP, for a serious problem, then they would be more likely to patch Win7 for lesser problems. Seems like jumping the default to MS's latest and greatest puts linux on MS's OS-release schedule -- especially when they haven't declared SMB2.1 as "bad"... From what I understand, most of the new security features in 3.0 when into SMB2.1 or 2.0. SMB3 is both secure and widely available: in Windows 8 and later, Samba and Macs. I can't find more recent stats than last Dec, but Win7 had between 2-3X the number of Win8 users AND Win7 had between 40-100% more uses than Win10. Win 8 was pretty much a non-starter. (http://www.zdnet.com/article/windows-10-versus-windows-7-whose-numbers-do-you-trust/) As of March 2017, another article showed Win7 growing w/r/t Win10: (https://www.theinquirer.net/inquirer/news/3005602/windows-7-market-share-rises-at-the-expense-of-windows-10) I can't say moving the default away from SMB1 seems like a bad thing -- especially if the error messages can be improved. Besides security, its notably slower, but many home devices still use SMB1 -- which is *fine*, if they are not exposed to the outside net. Then again, I've never put a Windows machine facing the internet -- don't think they are security enough -- use linux for that.
Re: RFC: 2.6.release.patchlevel: Patch against 2.6.release[.0] ?
Chris Wright wrote: The patches on kernel.org in v2.6/ are already against the base (i.e. patch-2.6.11.6.bz2 is against 2.6.11). The patches in v2.6/incr/ are incremental between -stable releases (i.e. patch-2.6.11.5-6.bz2 is against 2.6.11.5). I see. I had looked at the "Changelog" page on the www.kernel.org home page and only saw changes from 2.6.11.5->2.6.11.6 documented. I thought that the Changelog documented the changes that were in the patch. Maybe Changlog's that only document the current increment should be in the "incr" directory as well and be named "Changelog-2.6.11.5-6" (for the current change log, while a cumulative change log from the base version should be kept in the v2.6 dir? I think having the Changelog link on the main page only documenting the latest "incr", but having the patch containing everything from the base is confusing. Am I the only one who might expect the Changelog to document what is in the given increment, but the associated patch includes everything since the base? It's a "nit", I know, but I prefer having the change-log and patch to match w/respect to content. Linda - 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/
RFC: 2.6.release.patchlevel: Patch against 2.6.release[.0] ?
Given the frequency with which stabilization patches may be released, it may not be practical to expect users to catch each release announcement and download each patch. Especially if small patches are released for stability, as one might (hopefully) expect. Assuming that stability and "fix-it" patches will generally be small (I'd hope). Seeing that the latest "fix-it" patch is already at ".6", I'd have to load multiple patches to catch up from 2.6.11. I blinked my eyes and missed a few or 5 previous stability patches, so I just downloaded the entire bzip...not a biggie, but might create less load on servers if I didn't need to go through 6 patch applications to get current. What do people think? Would it be desirable to have the stability patchsets based against the base release (2.6.11 in this case)? I'll already have downloaded 2.6.11 or the previous base release, but with the frequency of patch releases, it might be more reasonable to have patch revisions all patch against a base release rather than having to download and apply what may grow to be a large number (but small diff) against a base release? Do people think patch-releases will get too big, or might it not be easier to apply them to a constant downloaded copy of the base? It's a bit amusing since I was one of those that complained about the kernel stability, but 2.6.11 has been fairly solid for me, so, of course, I'm 6 patches behind -- I don't think the patch release notifications are getting as wide-spread press (or at least not reaching "/." :-)) as the main releases get. Linda - 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: [PATCH] typo fix in Documentation/eisa.txt
Rolf Eike Beer wrote: Typo fixes. Thanks to Randy Dunlap and Jean Delvare. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- linux-2.6.11/Documentation/eisa.txt 2005-03-02 08:38:12.0 +0100 +++ linux-2.6.12-rc1/Documentation/eisa.txt 2005-03-27 21:58:04.0 +0200 @@ -171,9 +171,9 @@ virtual_root.force_probe : Force the probing code to probe EISA slots even when it cannot find an -EISA compliant mainboard (nothing appears on slot 0). Defaultd to 0 -(don't force), and set to 1 (force probing) when either -CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set. +EISA compliant mainboard (nothing appears on slot 0). Defaults to 0 +(don't force) and set to 1 (force probing) when either +CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING is set. --- 01234567890123456789012345678901234567890123456789012345678901234567890123456789 My expertise is limited by a fuzzy memory, and I know it's bad form to comment much on english usage or spelling as they are often tangential to the issue at hand, but as long as we are on the topic, I think you had it right the first time. I believe the comment, properly used the "imperative": declaring intended usage of the variable, i.e. - "Do this or do that"; "Default to 0 or set to 1". To use a perl like example: # set probe action: probe=0; # default to 0 (don't force) probe=1 if (X || Y); # and set to 1 (force), if either X or Y is set If you use "Defaults", then I think that's an implied 3rd person singular usage and for correct parallelism, the parallel clause (after the "and") should use the same tense. Third person tense for "set" would use "is" as a passive-voice auxiliary: "[it] is set to 1..." Saying "default to 0" is like the perlism: setup values of v: v=0; # default to 0 v=1 if (X || Y); # and set to 1 if X or Y is set I can't believe we are discussing grammer concerns in comments in the linux-kenel. :-) (!). -linda - 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: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)
Adrian Bunk wrote: On Sun, Mar 27, 2005 at 11:21:58PM +0200, Jean Delvare wrote: There are two cases: 1. NULL is impossible, the check is superfluous 2. this was an actual bug In the first case, my patch doesn't do any harm (a superfluous isn't a real bug). In the second case, it fixed a bug. It might be a bug not many people hit because it might be in some error path of some esoteric driver. If a maintainer of a well-maintained subsystem like i2c says "The check is superfluous." that's the perfect solution. But in less maintained parts of the kernel, even a low possibility that it fixes a possible bug is IMHO worth making such a riskless patch. --- I'd agree in [al]most any part of the kernel. Unless it is extremely time critical code, subroutines should expect possible garbage from their callers. Just because it may be perfect today doesn't mean someone down the line won't call the routine with less than perfect parameters. It used to be called "defensive" programming. However, in this case, if the author is _certain_ the pointer can never be NULL, than an "ASSERT(card!=NULL);" might be appropriate, where ASSERT is a macro that normally compiles in the check, but could compile to "nothing" for embedded or kernels that aren't being developed in. -linda Thanks, Jean Delvare cu Adrian - 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: Linux 2.6.11.1
Many, many thanks...it's a great idea and seems to go well with Linus's idea of making even releases "hyper-stable". This is exactly what I was looking for in (http://article.gmane.org/gmane.linux.kernel/268836) Sorry some of you feel like "suckers"...but you're _not_. You're heroes -- doing the hard sh*t that most programmers don't want to be bothered with. I salute you! Linda W. Greg KH wrote: For those of you who haven't waded through the huge "RFD: Kernel release numbering" thread on lkml to realize that we are now going to start putting out 2.6.x.y releases, here's the summary: A few of us $suckers will be trying to maintain a 2.6.x.y set of releases that happen after 2.6.x is released. It will contain only a set of bugfixes and security fixes that meet a strict set of guidelines, as defined by Linus at: http://article.gmane.org/gmane.linux.kernel/283396 Chris Wright and I are going to start working on doing this work, we will have a @kernel.org to post these types of bug fixes to, and a set of people we bounce the patches off of to test for "smells good" validation. We will also have a bk-commits type mailing list for those who want to watch the patches flow in, and a bk tree from which changsets can be pulled from. Chris and I will be hashing all of the details out next Tuesday, and hopefully all the infrastructure will be in place soon. When that happens, we will post the full details on how all of this is going to work. In the meantime, feel free to CC: me and Chris on patches that everyone thinks should go into the 2.6.11.y releases. But right now, Chris is on a plane, and we don't have the email alias set up, or the proper permissions set up on kernel.org to push changes into the v2.6 directory, but we have a few bugs that are needing to be fixed in the 2.6.11 release. And since our mantra is, "release early and often", here's the first release. --- I've released the 2.6.11.1 patch: kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz With a detailed changelog at: kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1 A bitkeeper tree for the 2.6.11.y releases can be found at: bk://linux-release.bkbits.net/linux-2.6.11 The diffstat and short summary of the fixes are below. I'll also be replying to this message with a copy of the patch itself, as it is small enough to do so. thanks, greg k-h --- Makefile |2 +- drivers/input/serio/i8042-x86ia64io.h |6 +++--- drivers/md/raid6altivec.uc|4 3 files changed, 8 insertions(+), 4 deletions(-) Summary of changes from v2.6.11 to v2.6.11.1 Dmitry Torokhov: o Fix keyboards for Dell machines Greg Kroah-Hartman: o Linux 2.6.11.1 Olof Johansson: o Fix for trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec Rene Rebe: o trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec - 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/ - 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/