Re: WARNING in sysfs_remove_group

[Dmitry Vyukov]

On Fri, Oct 27, 2017 at 11:23 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Oct 27, 2017 at 11:10:08AM +0200, Dmitry Vyukov wrote:
>> On Fri, Oct 27, 2017 at 10:43 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> > On Fri, Oct 27, 2017 at 01:29:31AM -0700, syzbot wrote:
>> >> Hello,
>> >>
>> >> syzkaller hit the following crash on
>> >> 4ed590271a65b0fbe3eb1cf828ad5af16603c8ce
>> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> >> compiler: gcc (GCC) 7.1.1 20170620
>> >> .config is attached
>> >> Raw console output is attached.
>> >>
>> >>
>> >>
>> >>
>> >> sysfs group 'loop' not found for kobject 'loop1'
>> >> ------------[ cut here ]------------
>> >> WARNING: CPU: 0 PID: 21947 at fs/sysfs/group.c:237
>> >> sysfs_remove_group+0x156/0x1a0 fs/sysfs/group.c:235
>> >> Kernel panic - not syncing: panic_on_warn set ...
>> >
>> > It's a warning that someone did something wrong with their code, any
>> > hint as to how you are triggering this?
>>
>>
>> There are some hints in the log. The warning says "Comm:
>> syz-executor1", which usually means that the warning was triggered by
>> the first preceding program labeled "executing program 1:". In this
>> case it's this one:
>>
>>
>> 2017/10/26 21:00:50 executing program 1:
>> getsockopt$inet_sctp6_SCTP_AUTO_ASCONF(0xffffffffffffffff, 0x84, 0x1e,
>> &(0x7f0000728000)=0x0, &(0x7f0000cc8000)=0x4)
>> mmap(&(0x7f0000000000/0xfe1000)=nil, 0xfe1000, 0x3, 0x32,
>> 0xffffffffffffffff, 0x0)
>> perf_event_open(&(0x7f0000a07000)={0x2, 0x78, 0xdb, 0x0, 0x0, 0x0,
>> 0x0, 0x0, 0x0, 0x0, 0xfe, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> 0x0, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0}, 0x0, 0xffffffffffffffff,
>> 0xffffffffffffffff, 0x0)
>> mmap(&(0x7f0000000000/0xfff000)=nil, 0xfff000, 0x3, 0x32,
>> 0xffffffffffffffff, 0x0)
>> perf_event_open(&(0x7f00008a8000-0x78)={0x0, 0x78, 0xdc, 0x0, 0x0,
>> 0x0, 0x0, 0x0, 0x0, 0x0, 0xfc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 0x0, 0xffffffffffffffff,
>> 0xffffffffffffffff, 0x0)
>> perf_event_open(&(0x7f000002f000-0x78)={0x0, 0x78, 0x0, 0x0, 0x0, 0x0,
>> 0x0, 0x0, 0x0, 0x0, 0xd34, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 0x0, 0x0, 0xffffffffffffffff,
>> 0x0)
>> r0 = syz_open_dev$loop(&(0x7f000060f000-0xb)="2f6465762f6c6f6f702300",
>> 0x200000000000001, 0x800000102)
>> r1 = memfd_create(&(0x7f0000000000)="fff8", 0x0)
>> writev(r1, &(0x7f000005f000-0x90)=[{&(0x7f000008d000)="479ac0310b7c6b1fbf668c4ea110c3148a20ce155f1e909e4e6d0170137fd7e54f1516bc7a12a912f5e03a9264b0db2ec5e38d302349761abe4a49e3908adc",
>> 0x3f}, {&(0x7f0000842000-0x1000)="a88ea16465a8bb8f7edf2f5df1acb3fdfe4cc92f98b85d50410879df687a0348c62ec96530ce8f33c84088abff5e302fb8e9e90a4a812993d385b709b7d0ff42369ca37886eadbf5c8288383c02ba5c20f9bc216532d99ea7752c6263a143acc961d63eb08b7d19eaa86384883d333ca4d6e0955a3fbe38adf1b845f8eb9675afd785ed47f66237a6f7c96cae0336b27a4ec51557cdafffb70952daa2d781d6add47a5e015954586a97941f561b10ad8f348601db77d27d7724be43ece2fe6ae243ec1370f870110330f8926c781c0e388c68ce64263ce603e16741ed17c1048f71f614f2846ccaad9c8f295d89d3d3999548f4d0d35c955b5ba497291febd4f04209553c83da7215489f834887d4df09e99dcc6acc42b2ee73e0d07d6b7b17ceae2db3ca64b1b5b719127bc8de8ec3318faf1b42cd00ba90aabf52364118ae7faa38bb61748f92bc59cedc11e8f94fd59be548697d6adc63d67905c4700cb18aa5516270af8a55c076a2a5c28923bc50645fad5f0e0603c2838fcd956e9adc4aa65974a313b68aec078ec0991a344608c5c19425074147e1877c024d0fd51232e7b7bbaf49a310b724f7d2ac8c5c85b1222382121efc20bc138fbb5b097f5b7ec1ad0",
>> 0x1c3}], 0x2)
>> ioctl$LOOP_CHANGE_FD(r0, 0x4c00, r1)
>> sendfile(r0, r0, &(0x7f0000e59000)=0x0, 0x200000000000006)
>> ioctl$LOOP_CLR_FD(r0, 0x4c01)
>> ioctl$sock_inet_tcp_SIOCINQ(0xffffffffffffffff, 0x541b,
>> &(0x7f000099a000-0x4)=0x0)
>> getsockopt$inet_mtu(0xffffffffffffffff, 0x0, 0xa,
>> &(0x7f00001b0000-0x4)=0x0, &(0x7f0000d5a000-0x4)=0x4)
>> pipe(&(0x7f0000fc4000)={0x0, <r2=>0x0})
>> setsockopt$ALG_SET_KEY(0xffffffffffffffff, 0x117, 0x1,
>> &(0x7f0000316000-0x25)="", 0x0)
>> ioctl$EVIOCGSW(r1, 0x8040451b,
>> &(0x7f000048d000-0xb)="000000000000000000000000000000000000")
>> setsockopt(r2, 0x1, 0x9e7,
>> &(0x7f0000a82000)="0ecf7c7e3c508947370f71cde09f5f58d8e13313f3404aebb022ef3401666bb11f1872a51d7a551ffcb2fa1260aca621feb43e6e00858dd9a222836f10cbbd338c9d169a8f0d4c4784435ba9a947cbdb0c7ead20bf1fc85ef14d1a59deb8c710a86308390ec408bb2b261e111143750a66fc2b262e635b6a80441b24748f5d6ac05a7c3e173bff8e5e86cf06d07354d41f8e2de862ad824ee0b6eb143d987e345f816f243ae2b8d7e21b081e1f18701f84aa443a2f415ea9060ee20c52fcf06396083933cc42fe7b61f504d7d79eb3fe325404e73a7be31122c0eef637530926e857cb1908aa23fe39f86753c2906149a5cbfc45f21a6d30380068150be3e020ce2f5e40aeaa8bb2617e87de12fcef5d03fc20c2049891b68a1defff59daa542b7831fb22f752b7382a47bcf32e1f8a465f5c7775ccbde31f7e2bd2dee00779ad12c49df2cfd135c5a1d6ef7c8659a02a06ffc66aeb5a192267a1c1cf511048c012f0c99e830180995615d6d049181d179674c08e7eed0789e6f5832a5b4d8752389c0e7c6f5fba75a78d0db3313a7b3d3d3c9592bf3b5f4d76cd8e842f9efcd6a656128198ec78d0d0dfd58a3a8f27c532431b9fb250454655799cf56f9652856fbc0722c6f6f9626e442ae9a897d110adc4dea3495e8eb245d52ce07c21634a50366e84523c6ed8afb1840ec6be3f647d07365f37f9f440a33d9a7151e2a7d062a7d0134711abfba4bc97b8cd317e761d9fa81e4148f9f9897312d8777ef3a05152757854c629dcdabe367eaeef0b3c0063badb867dc0dd92a0ba4fd34e2e5cd82baafcf43283851fc9ad0c50b3d3fecc25dd6c4a40be95e35932fcdad96a8d21dee38b737fcd8a19848fcbc5569dc6d344200d9321bc92b85965ed47042a1e9eb0c6a823c0ecd2a9882b9de4bd5d72961f7c16c53cf9ec9dde7e1a6f1473451e96e5966783a39373216812f0dd4fc4c18862048e2edb8db2766dc116ab99ae05c5d3f7d03e12f7a8369ab12cb04cc258122efd587daf0da4109b63df8f33d6c871b642533234771f46322425b9635c3d2ebc996c871a6a4760f56d96ba04378b7f5ae48ac5781601251f8bf863eae284b64ad43931b20ce9c571c777c36aef09b0dc7c4e38ff0959d6f09cb3b75228f0afc62d3695d845ebca21bbaf314d90b8c1f4357dc651505407dcd345f7e88b0c9c8acc93d746138b911a5b4a62b0b6f4b020c8150576c67e513a52cbc0b99a5f3e0f2d148ee86f69197a1d76298215f8de7727605a59e6da754c940cd14a897b0636935616e05afe7c670b956e5a703724124be7fb029bc38d5af4741f4e8a44d501c0e070a60b4534f0c92339ad62b58b26e5060ec831a38956b6d923c32012c64452e4d7c7f9fd3b60f60ea402755e669e8e5d12e3468ab1c3ccae5acc61135e04757da27fbb44adca61b3128019b24fb05585d557eb3a2ceb2fecbe8f367a970f0d34c00bcd9fae1a8f225ae94aae9bd901db2294205104bf2a5f48e418a3e85415cadceb44ee76b76cbe16f1b25f6f242859957e77f76fc8f869eea5ca97ef113c2f7217049dfe893ec5fdc85b22ecbfd1ee3fc2fac02349e79cb8e8de569cce72110f0ef0398129b1c1bf610afcd4a663e33e6bb32d9f88190c81659279b3aa0d952127fc8784b51fe23b2e22a516033ac5e99bf014ab88c7cf696d26a614806c8c9690f5e4f67a25cdeeac605928607540ae0acf9fc500c61fc10070a6e598ba16b291808b0976adbb034251e0e96e7813c1ba718218c955b35c16a894da7d63cb570f8124f8dc32e1119feb07f8f47bf92145f2ecacc0cb4f02e741a214543e7461630a61a7edf1db866c850c5e9eef4b57b7b4042a5f473f7f2d415ccd89317f7a304830fc788eb9832fac8a5a2ab7580f43fa8b10aaed1621733ed10c0880af740fc5d8fccd6fb26e162149f2d39bf1a7882829bd8a8192a0e04d016dc0f903a04cacb041eab1bb0797e28f23091cab001868c73a2ddd7923e861aab2f1ecf9bb84578d5f5b375a4a121e547de927c3e6718c0454680b07cab63acf2fe2a7021bfd27813ef6d32a802051d6d6ec9571f36d1f472f4935e68778fbae68457504291d73d909e276efa1d6f95f2e0cf90460a97bf5c7ad737f058cbd68277cc49f042ca8fdf9245ec40ddc5dcca716656edde2c30e7ffd40422f9bd4c009b9d4fcaf2c9b27dd65f3f4ec659cdcc9095a4d3c931693c86eb7259eb68f5b50a173c71351b4ef75106dfb41f48ba7fb5be65452c0bafa04c926d985e4330a9ecfa869d7ba88a855826e0fa63b257e91618e66076f49e2b42cba2e41a490b848f0185c0d7527c6443cacdc8beb8ed8ea7fac1ba7c0adb17f7c4a0aaf204bcae348c3e9965506ef8e96dbf47ad637c0deeb4b7278338bb74647b515f014b9fd65aa1899eaeb1f7a8d932df8d015e9178f01d0d6c506cd4adb26939c035e76eea548fda470f3a6a070d11af5578275c054cc38b37fec3b036122eef8553450ad092b921a3c6d20f0aae78fbead3821d37b5242be2af4314486b0e3c8213472725d13a2fbffc3d7b97895cb2efe9ff4fd207efa83077ebc5038a385b4f56d1c727573101cdebd1e200a6629ba67f09768c9c8c5457194e3cdb8dac3ba11ea8956155f173d53d3e5b3d637aa487960ec3bff1ac8c9bfca97356920c160e6f7ed49d2dfd5efd911c0f1d0b608308ad6a0ff57384b6013c18942259b6c2c09cd485c622bef165be0019a39fe25cd3a5baaa5f59a90d32d80e0178a7bacfd67a9b743d96f8abf823e1c7884b60a233c115eacd1019bb0220314cd050f25cee92d1746d87805712371c71f358cd19b23f5eda9f7b1f40dcce9bad0ce4e4a4eddb93d38c231c5e437c7698a5e987d390a6388ce9620ff889bb8618558b5ff4a74d7f751c612545eab5275704b59db73e8831b496ef285a6690f0af702be8c42a7ea3e5d42a58313907b57c642af83379bfecc3a7f6e8780b64aa2e5cd8dd53f472568cee59e57c9621a92dce2179ed1967fa7307c7abdf52016e265b11689c9d45e20f5e5d40767f64af274ab5d15bdd683d4a6432d1d1282ffa5995097db96e70a21f1a0caff5eb1c8b0fe628386be10856533a8587041e716ea065360d7abb16d5649759df4688db63945a9e87b53389d2858a557d5922ecc20d0953ed44bc7dcd9979ce95da92549c968f9a1ebb1aa77f601c68493ad41d133368b7f9770cb7fc0d0e2bb9b9a52c3c949779a32b525158a1c140db44e27c38ebfd213be7d4db460fe78aecada73ab32ef1876becf605def866396f92965789d4096eee5eed26f71b0925c97069a1faf7bd81db3d3d51dba83297b68f30fdb8eb8e921a7d86bfcabc5661188b3ede74b5dcd5d3c72677908d421284c82cda36f198dd5dfc01608e204441f76adb8f7d05b0b8c357859d95b5174e0570ee6b2ab2b1831121b1ae2f64a295349fbcf911fafff7a4243978e72ebca761060f3959669c9364d989899eb8a82cf85c425dccab04e0da9511cad9955543e57a43324eb92666b59524b15d6fb287b47aeb3ffbdf186ad7f5f1278cc20cfe849716abe9bfef465dde57ef2c4682db59aef9d436b7d34b14cc1cc6615b66b839ec92b42eb53b51497aa5edc59537baecd367c343c0365dc36ea9e9c6131f0146efced986837fe4e4597fc77a4c7fe69181cab2c87d2dd688a19e4b0096972966a63e044f07dca226c818d12467cc4ef6f90ba6955ed41666ab24bf4bb31f6659a147c4f6ca403cc97a15a6edacee68586f7d54313ba736959c843215250f6c9c5efbcc3eed31987ceed6298269e06f803f78a3e78edcaab68be19d72d75a8a0d400467286ed2dc4a99978f05d587a224f728b866278716817d4084fda580530b4a5eb08328bc6d7c78daf4d938f396ba65dff259996ff8c193fe61fcc2a28359dcaae59891e8962346669447a7cfbcf470b3a1bad0e728b13ee7ae4267cb09df781f67759cede0c6cfe3f22bf9b546fec2c7f5488853c2077d04787250ebb5130ec02ad04d1423a280ec768340e1b5dbd9436a70161e9d9fff00fe2896b4c921659edee53134274e94599a580ec251e20cd27a99e68080cd781a7172e5a8a792d8764391927f10fd3a866ace333e0b1401dcfbf3e852ab29c080f49e53e55dfaeec607293aaa969582c27b4e1f4ad9dd05fff6c4fc6e0cd5ba3fb1d2b40196feb03c308e7621f6283c4aac5ac93973164c1e781d0443a6a47110271d47e80c6a50d15ea9ff05e51283decfa542e777bee7d9dbb634e080c502156fa9f087f907a9d009a40b1c801a73412ec69e58d62216d6bbe097898dbb5dbf4dc3044e30c203aa0c0757644c013bc78566ea94c46622d5ec127a7cc776d799bc88803d9bc141f416ae6eef09582b2f62e725d8a030fe4dbc0ae9b7ec1993a87939903e664cf1842d2a5f5c7b7cf7ee2d45aa710e771a3ad595b97c48f36a5bbbf6bfc6fb3d74c0002fd437cafb7365e007a99f947bfa9cb904c8f0437ea6234d7ded3484fae2da627e73cc3605a887fa411e3977dfc5a18f845611323733cec311e548b17f1b0a4efda19e94d5ee8b64199e03f7900a56d28e638d87a24cfb9660792f93145e1115425e410d21ba17fdd40baf407be8a4039a50359b8196b5f4f4b4af83d6bab318c8e7cc5d6e9b2c97d98a6007387f4cb79880b5d20bfb11b40521286617277dfe29b374d42752edc4224ba67228eabb11348f6de6ca41bfc52be63e9f0ec5d25914cfe8f93f50cc73f57b17f800a0344eaf1e66b09c568d2b2489a8317ddae4e54df27fdb327f28f020094c32d700923efd11880eb964a5309411b351879782b07282994318d65d86b4ab05c5bd0569088983963f47ffebd830f25fb3a33c246c0718ec92c46a1da78d5fa20f5d3e4d4a799d116c3505a7b091f6e75bdc7ea387c0b97e5fc691ce26d2d3362abd5196a3347e216c0def60fd4ac14696d0064ee8640e738ac228b6c9c99e854494f05905fd950a6acda1aeb550ba69aa2f41efcd3e44e6ca1d431104133f8e8c89d5b1781437f4a217ae4dfe4cda215eb875afdb2eba77dd0f56a86b7e3f943fb2369f9b036c591845377a0a0b0a5711c2fa4964103a747f69a9106407125efd87e8a0898df550adfc54c075647c741ea1d0aad85acc9e8024de8453c97c60cb475395c57dd7803a39f1cdebf46e3a0e35810d9a96615e894981ea0b1b28d51a735c83952bef4a101bb193e507f147c707b21c1877788def6a7661d3fd08928fb2f1f82e55bf0405266ce35737cbc5ef01e16b77aad5198d632332ec5a02045f76175338403d0271ca224cc4e699cf749f7d52c6776c491de072cf67a7ea56c2906cc052b05451f231e57633b7fd2280266e53d878cacb0f12559cefd38a31496fd0d174244f761efeeb0723e95bf00da79324af19b3ccca91a213669d50d2b2690e473e3fbb4219290aec08e4add2a89dc34be2f944797bd35c354e16ba4bd2f967fee3b546d5f5161f9d0519b69634b83a0169715a52bf4828ec9a00c484ad9eed8843590f9eaa7c35938a74f2e277f2c552bf78f1aba78d26b5ef369ae163f9f1924229034828cb094715f25ac8e4df46b6986513e88a61e72589601ee948673b01cc36dd292a45f8a2865ca6390f6997d74621d59b37854e5c046183fe9def9420698932e3d2f20854c7fe0d548cf6f9c7c6bbda801a4827a80170eb5f8c790886db4a0eab911ccc4b0059069df9feb5d9c86b9de7155d4f8c03925a0d7fbe73b9cc7589360115ba052de5",
>> 0x1000)
>>
>>
>> Syscalls related to loop device are:
>>
>> r0 = syz_open_dev$loop(&(0x7f000060f000-0xb)="2f6465762f6c6f6f702300",
>> 0x200000000000001, 0x800000102)
>> r1 = memfd_create(&(0x7f0000000000)="fff8", 0x0)
>> writev(r1, &(0x7f000005f000-0x90)=[{&(0x7f000008d000)="...", 0x3f},
>> {&(0x7f0000842000-0x1000)="...", 0x1c3}], 0x2)
>> ioctl$LOOP_CHANGE_FD(r0, 0x4c00, r1)
>> sendfile(r0, r0, &(0x7f0000e59000)=0x0, 0x200000000000006)
>> ioctl$LOOP_CLR_FD(r0, 0x4c01)
>>
>>
>> But there were other processes messing with loop 0 around the same
>> time. The preceding "executing program 3" and "executing program 2"
>> also mention syz_open_dev$loop.
>> And note that some syscalls in a program can be executed in parallel.
>> So unfortunately there were lots of things happening with the loop 0
>> (/dev/loopN is quite unfortunate interface; say memfd_create easily
>> allows each process to mess with own instance, but loops are global
>> and there are only 8 of them which does not even allow us to partition
>> them across processes).
>
> Ok, that's a mess.
>
> This kernel warning is there for the developer to say "hey, you did
> something dumb, fix your code", but then sysfs recovers and moves on as
> it's not a fatal error at all.
>
> I think this goes back to your other email about "how do we detect a
> real error warning or not".  Right now we don't have a way to
> distinguish between warnings like this (where the kernel core is telling
> higher layers to not do foolish things, but it is a recoverable issue),
> or where a "real" warning happens that can cause real problems with the
> continued operation of the kernel.
>
> I don't know what to suggest here, maybe some way to distinguish between
> the two would make it easier for automated tests like what you are
> doing?  Some different type of WARN_ON_DEVLOPER_IS_STUPID() message?


The overall problem is still an issue for us, which I would like to
resolve in future.
But I think if the problem with higher levels of kernel code (rather
than with user inputs, including insane concurrent sequences of
syscalls), it's still a problem with kernel code, for which a WARNING
is a reasonable thing. And an action point for such things would be to
forward this to higher-level code maintainers to fix the code to not
do stupid things with lower level APIs. If a firing WARNING is in a
source file, it does not mean that the root problem is also in this
file, it's just that this code detected the problem.