* Shares with strange ACL settings @ 2015-08-11 8:42 Achim Gratz 2015-08-11 17:20 ` Andrey Repin 2015-08-12 15:26 ` Corinna Vinschen 0 siblings, 2 replies; 40+ messages in thread From: Achim Gratz @ 2015-08-11 8:42 UTC (permalink / raw) To: cygwin I've thought some more about those strange shares I need to use that have inherited ACL that don't let me change the ACL at all and hence prevent Cygwin from fixing up the POSIX permissions. That generally ends up with permissions like these: % ll test total 10 d---rwx---+ 1 gratz Domain Users 0 Aug 10 11:51 ./ d---rwx---+ 1 Administrators Administrators 0 Aug 10 11:50 ../ ----rwx---+ 1 gratz Domain Users 18 Aug 10 11:51 blafasel* ----rwx---+ 1 gratz Domain Users 18 Aug 10 11:51 blumblum* Some applications that know how POSIX ACL are supposed to work conclude that such directories or files are not readable: % cd test % perl -E 'say -r "." ? "readable" : "not readable";' not readable % perl -E 'say -r "blafasel" ? "readable" : "not readable";' not readable Other applications not using this shortcut and going all the way to faccessat correctly determine readability: % [ -r . ] && echo readable || echo not readable readable (1056)/mnt/upload/test > [ -r blafasel ] && echo readable || echo not readable readable If I access the files from another account (that has the same group memberships that give read/write access to the share) or change the owner, then the shortcut is never invoked: $ perl -E 'say -r "." ? "readable" : "not readable";' readable $ perl -E 'say -r "blafasel" ? "readable" : "not readable";' readable $ [ -r . ] && echo readable || echo not readable readable $ [ -r blafasel ] && echo readable || echo not readable readable So, it would probably help if I had a mount option to force the ownership to some account that I am never logged in as, either via a mount option or whenever the POSIX user modes are all cleared. I don't know if that might confuse applications when they check ownership on newly created files, though. Is that something that is implementable easily so it could be tested via a snapshot? Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-11 8:42 Shares with strange ACL settings Achim Gratz @ 2015-08-11 17:20 ` Andrey Repin 2015-08-11 17:29 ` Achim Gratz 2015-08-12 15:26 ` Corinna Vinschen 1 sibling, 1 reply; 40+ messages in thread From: Andrey Repin @ 2015-08-11 17:20 UTC (permalink / raw) To: Achim Gratz, cygwin Greetings, Achim Gratz! > I've thought some more about those strange shares I need to use that have > inherited ACL that don't let me change the ACL at all and hence prevent > Cygwin from fixing up the POSIX permissions. That generally ends up with > permissions like these: > % ll test > total 10 > d---rwx---+ 1 gratz Domain Users 0 Aug 10 11:51 ./ > d---rwx---+ 1 Administrators Administrators 0 Aug 10 11:50 ../ > ----rwx---+ 1 gratz Domain Users 18 Aug 10 11:51 blafasel* > ----rwx---+ 1 gratz Domain Users 18 Aug 10 11:51 blumblum* > Some applications that know how POSIX ACL are supposed to work conclude that > such directories or files are not readable: > % cd test > % perl -E 'say -r "." ? "readable" : "not readable";' Perl is known to have "special" treatment of file permissions. This issue has been raised in the list before. > not readable > % perl -E 'say -r "blafasel" ? "readable" : "not readable";' > not readable > Other applications not using this shortcut and going all the way to > faccessat correctly determine readability: > % [ -r . ] && echo readable || echo not readable > readable > (1056)/mnt/upload/test > [ -r blafasel ] && echo readable || echo not readable > readable > If I access the files from another account (that has the same group > memberships that give read/write access to the share) or change the owner, > then the shortcut is never invoked: > $ perl -E 'say -r "." ? "readable" : "not readable";' > readable > $ perl -E 'say -r "blafasel" ? "readable" : "not readable";' > readable > $ [ -r . ] && echo readable || echo not readable > readable > $ [ -r blafasel ] && echo readable || echo not readable > readable > So, it would probably help if I had a mount option to force the ownership to > some account that I am never logged in as, either via a mount option or > whenever the POSIX user modes are all cleared. I don't know if that might > confuse applications when they check ownership on newly created files, > though. Is that something that is implementable easily so it could be > tested via a snapshot? -- With best regards, Andrey Repin Tuesday, August 11, 2015 20:04:58 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-11 17:20 ` Andrey Repin @ 2015-08-11 17:29 ` Achim Gratz 0 siblings, 0 replies; 40+ messages in thread From: Achim Gratz @ 2015-08-11 17:29 UTC (permalink / raw) To: cygwin Andrey Repin writes: > Perl is known to have "special" treatment of file permissions. It's perfectly valid to do this from a POSIX perspective and Perl is not the only program to do this (but it's easier to show the result with Perl). As far as POSIX is concerned, the mode bits that Cygwin presents are wrong given the actual access rights of the underlying Windows DACL. > This issue has been raised in the list before. By me, so yes I know. What's your point? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-11 8:42 Shares with strange ACL settings Achim Gratz 2015-08-11 17:20 ` Andrey Repin @ 2015-08-12 15:26 ` Corinna Vinschen 2015-08-12 15:50 ` Achim Gratz 1 sibling, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-12 15:26 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2864 bytes --] On Aug 11 08:42, Achim Gratz wrote: > I've thought some more about those strange shares I need to use that have > inherited ACL that don't let me change the ACL at all and hence prevent > Cygwin from fixing up the POSIX permissions. That generally ends up with > permissions like these: > > % ll test > total 10 > d---rwx---+ 1 gratz Domain Users 0 Aug 10 11:51 ./ > d---rwx---+ 1 Administrators Administrators 0 Aug 10 11:50 ../ > ----rwx---+ 1 gratz Domain Users 18 Aug 10 11:51 blafasel* > ----rwx---+ 1 gratz Domain Users 18 Aug 10 11:51 blumblum* I don't know what to do about this. We're talking back and forth about reflecting group perms into user perms and whether we do it or not, it always seems to have some downside on some installations. A reworked implementation which takes the exact user perms into account in a Windows environment, and which works from a normal user account is a major undertaking. I doubt I'll have the time to implement something big any time soon. > Some applications that know how POSIX ACL are supposed to work conclude that > such directories or files are not readable: > > % cd test > % perl -E 'say -r "." ? "readable" : "not readable";' > not readable > % perl -E 'say -r "blafasel" ? "readable" : "not readable";' > not readable > > Other applications not using this shortcut and going all the way to > faccessat correctly determine readability: > > % [ -r . ] && echo readable || echo not readable > readable > (1056)/mnt/upload/test > [ -r blafasel ] && echo readable || echo not readable > readable > > If I access the files from another account (that has the same group > memberships that give read/write access to the share) or change the owner, > then the shortcut is never invoked: > > $ perl -E 'say -r "." ? "readable" : "not readable";' > readable > $ perl -E 'say -r "blafasel" ? "readable" : "not readable";' > readable > $ [ -r . ] && echo readable || echo not readable > readable > $ [ -r blafasel ] && echo readable || echo not readable > readable > > So, it would probably help if I had a mount option to force the ownership to > some account that I am never logged in as, either via a mount option or > whenever the POSIX user modes are all cleared. I don't know if that might > confuse applications when they check ownership on newly created files, > though. Is that something that is implementable easily so it could be > tested via a snapshot? I'm not sure I understand the idea of mounting w/ an explicit user account and how this might help. What about just using the noacl mount option for weird shares like the above? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-12 15:26 ` Corinna Vinschen @ 2015-08-12 15:50 ` Achim Gratz 2015-08-12 15:58 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-12 15:50 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > I don't know what to do about this. We're talking back and forth > about reflecting group perms into user perms and whether we do it > or not, it always seems to have some downside on some installations. Since there are fundamental differences between how Windows evaluates ACL vs. what POSIX expects this problem isn't going away anytime soon. Depending on how much control you have over the default or inherited ACL you can pretend these differences are non-existing with varying degrees of success. Another fly in that ointment are the Backup/Restore privileges, but these you can control if you are aware of them. > > So, it would probably help if I had a mount option to force the ownership to > > some account that I am never logged in as, either via a mount option or > > whenever the POSIX user modes are all cleared. I don't know if that might > > confuse applications when they check ownership on newly created files, > > though. Is that something that is implementable easily so it could be > > tested via a snapshot? > > I'm not sure I understand the idea of mounting w/ an explicit user account > and how this might help. What about just using the noacl mount option > for weird shares like the above? That mount option would ensure that the ACL are actually consulted by a POSIX application when the user mode bits are all cleared since the file would appear not to be owned by the (E)UID. The only other option I can see would be to augment stat to traverse the DACL when both these conditions are met: the file is owned by the (E)UID of the calling process and the user mode bits are all cleared. That is, do the faccessat on behalf of the application that it would otherwise (likely) do if the file was _not_ owned by the user. Of course you can't really know why stat was called and that might impact perfromance quite noticeably. As to "why not use the noacl option", that makes the file mode tests completely useless and requires more elaborate error handling that would otherwise not be necessary. Some users and scripts they have written are not prepared for that extra complication. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-12 15:50 ` Achim Gratz @ 2015-08-12 15:58 ` Corinna Vinschen 2015-08-12 18:09 ` Achim Gratz 2015-08-13 17:56 ` Achim Gratz 0 siblings, 2 replies; 40+ messages in thread From: Corinna Vinschen @ 2015-08-12 15:58 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2999 bytes --] On Aug 12 15:50, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > I don't know what to do about this. We're talking back and forth > > about reflecting group perms into user perms and whether we do it > > or not, it always seems to have some downside on some installations. > > Since there are fundamental differences between how Windows evaluates ACL > vs. what POSIX expects this problem isn't going away anytime soon. > Depending on how much control you have over the default or inherited ACL you > can pretend these differences are non-existing with varying degrees of > success. Another fly in that ointment are the Backup/Restore privileges, > but these you can control if you are aware of them. Cygwin is aware of them and access(2) explicitely checks for them. That obviously doesn't help for applications like perl, who "know better" than the underlying OS how to evaluate perms. > > > So, it would probably help if I had a mount option to force the ownership to > > > some account that I am never logged in as, either via a mount option or > > > whenever the POSIX user modes are all cleared. I don't know if that might > > > confuse applications when they check ownership on newly created files, > > > though. Is that something that is implementable easily so it could be > > > tested via a snapshot? > > > > I'm not sure I understand the idea of mounting w/ an explicit user account > > and how this might help. What about just using the noacl mount option > > for weird shares like the above? > > That mount option would ensure that the ACL are actually consulted by a > POSIX application when the user mode bits are all cleared since the file > would appear not to be owned by the (E)UID. The only other option I can see > would be to augment stat to traverse the DACL when both these conditions are > met: the file is owned by the (E)UID of the calling process and the user > mode bits are all cleared. That is, do the faccessat on behalf of the > application that it would otherwise (likely) do if the file was _not_ owned > by the user. Of course you can't really know why stat was called and that > might impact perfromance quite noticeably. It does. Another, *very* simple idea is this: Spill the group and other perms into the user bits only if the owner of the file is the current user. Would that help? > As to "why not use the noacl option", that makes the file mode tests > completely useless and requires more elaborate error handling that would > otherwise not be necessary. Some users and scripts they have written are > not prepared for that extra complication. But there's no additional checking necessary because the perms are guarded by the OS anyway. The applications just don't know them exactly. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-12 15:58 ` Corinna Vinschen @ 2015-08-12 18:09 ` Achim Gratz 2015-08-12 18:32 ` Corinna Vinschen 2015-08-13 17:56 ` Achim Gratz 1 sibling, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-12 18:09 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > Cygwin is aware of them and access(2) explicitely checks for them. That > obviously doesn't help for applications like perl, who "know better" > than the underlying OS how to evaluate perms. Perl is making use of an explicit guarantee in POSIX' ACL specification, placed there in order to be backwards compatible to a system without ACL. Whether it is a good idea to do this is debatable of course and I might hunt that code path down in Perl and squash it in some future release. It nevertheless is chink in Cygwin's shiny armor of "hey, we're POSIX of the Linux flavor". FWIW, Git seems to have an explicit check for POSIXPERMS in order to sort out systems that don't conform exactly to that expectation. > It does. Another, *very* simple idea is this: Spill the group and > other perms into the user bits only if the owner of the file is the > current user. Would that help? I think so, but there are likely some corner cases. But I think that had been proposed and shot down already, so I was trying to come up with something less intrusive. > But there's no additional checking necessary because the perms are > guarded by the OS anyway. The applications just don't know them exactly. I have several scripts where tests for a readable file had to be replaced with a test for non-zero-size file or just existing file. Also, with the noacl option you'll always get a positive on most tests and if the code is unprepared to handle the inevitable failure on the actual access, then bad things can happen. Not every piece of code has already converted to the "let's try it and bail out when we get told to get off" style of file access. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-12 18:09 ` Achim Gratz @ 2015-08-12 18:32 ` Corinna Vinschen 2015-08-12 21:03 ` Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-12 18:32 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1659 bytes --] On Aug 12 20:09, Achim Gratz wrote: > Corinna Vinschen writes: > > Cygwin is aware of them and access(2) explicitely checks for them. That > > obviously doesn't help for applications like perl, who "know better" > > than the underlying OS how to evaluate perms. > > Perl is making use of an explicit guarantee in POSIX' ACL specification, > placed there in order to be backwards compatible to a system without > ACL. Whether it is a good idea to do this is debatable of course and I > might hunt that code path down in Perl and squash it in some future > release. It nevertheless is chink in Cygwin's shiny armor of "hey, > we're POSIX of the Linux flavor". > > FWIW, Git seems to have an explicit check for POSIXPERMS in order to > sort out systems that don't conform exactly to that expectation. > > > It does. Another, *very* simple idea is this: Spill the group and > > other perms into the user bits only if the owner of the file is the > > current user. Would that help? > > I think so, but there are likely some corner cases. But I think that > had been proposed and shot down already, so I was trying to come up with > something less intrusive. This is relatively unintrusive. The current user token is always available. So if owner == current user, for every group in the file's ACL just check if it's in the current user token and, if so, add the perms of that group to the owner perms. Sounds pretty neat as an intermediate solution to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-12 18:32 ` Corinna Vinschen @ 2015-08-12 21:03 ` Achim Gratz 2015-08-13 16:33 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-12 21:03 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: >> I think so, but there are likely some corner cases. But I think that >> had been proposed and shot down already, so I was trying to come up with >> something less intrusive. > > This is relatively unintrusive. The current user token is always > available. So if owner == current user, for every group in the file's > ACL just check if it's in the current user token and, if so, add the > perms of that group to the owner perms. > > Sounds pretty neat as an intermediate solution to me. I'd play the guinea pig for that snapshot… :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-12 21:03 ` Achim Gratz @ 2015-08-13 16:33 ` Corinna Vinschen 2015-08-13 17:48 ` Achim Gratz 2015-08-13 17:53 ` Corinna Vinschen 0 siblings, 2 replies; 40+ messages in thread From: Corinna Vinschen @ 2015-08-13 16:33 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2268 bytes --] On Aug 12 20:59, Achim Gratz wrote: > Corinna Vinschen writes: > >> I think so, but there are likely some corner cases. But I think that > >> had been proposed and shot down already, so I was trying to come up with > >> something less intrusive. > > > > This is relatively unintrusive. The current user token is always > > available. So if owner == current user, for every group in the file's > > ACL just check if it's in the current user token and, if so, add the > > perms of that group to the owner perms. > > > > Sounds pretty neat as an intermediate solution to me. > > I'd play the guinea pig for that snapshot… :-) This puzzles me a bit. As example you gave something like ----rwx---+ gratz Domain Users [...] foo Given the code in recent Cygwin versions, this shouldn't happen if the user gratz is member of the Domain Users group. The current code doesn't test all groups in the ACL, only the primary group, but that's sufficient in most cases. So this could only happen if you modify the permissions of windows files using Cygwin tools and Cygwin helpfully gernerates a DENY ACE for the owner. I'm just not exactly sure about the way to go to get these permissions in a non-artificial scenario. But I can reproduce it like this: - The file xxx has a primary group different from the group which has permissions, e.g.: owner: foo pgroup: foo_group acl: 1 entry bar_group: full control - ls -l xxx ----rwx---+ 1 foo foo_group 68565 Aug 10 10:37 xxx - $ chmod g-w xxx - Afterwards, the POSIX-like ACL looks like this: $ icacls xxx xxx foo:(DENY)(S,RD,REA,X) foo:(D,Rc,WDAC,WO,RA,WA) foo_group:(RX) Everyone:(Rc,S,RA) bar_group:(RX) So, what's going on here and how do we really fix it? It *might* be prudent to drop any efforts to create DENY ACEs to reflect the POSIX perms. That results in the documented permission gap between POSIX and Windows permissions, though. There's just no way to express all possible POSIX permissions using Windows ALLOW ACEs only. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-13 16:33 ` Corinna Vinschen @ 2015-08-13 17:48 ` Achim Gratz 2015-08-13 17:53 ` Corinna Vinschen 1 sibling, 0 replies; 40+ messages in thread From: Achim Gratz @ 2015-08-13 17:48 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > This puzzles me a bit. As example you gave something like > > ----rwx---+ gratz Domain Users [...] foo > > Given the code in recent Cygwin versions, this shouldn't happen if the > user gratz is member of the Domain Users group. The current code > doesn't test all groups in the ACL, only the primary group, but that's > sufficient in most cases. I've detailed the setup in an earlier post (with getfacl and icacls output) that I can't dig out shortly, but the setup is, in a nutshell: The share access is purely governed by two access groups, one that gives you the right to read and another one that lets you create and change things. You'll be in one or both of these groups in AD. All ACL are inherited from the root of the share down and the right to change the DACL (and thus remove that inheritance) is explicitly forbidden for anybody. The actual setup is a bit more complicated, with additional groups that ensure that share administrators can do what they need to do and that the backup can actually be done, etc.pp. > So this could only happen if you modify the permissions of windows files > using Cygwin tools and Cygwin helpfully gernerates a DENY ACE for the > owner. No, the owner just never gets the full access it would need to do this. For a while they didn't even let you look at the DACL, but at least that part of the silliness has been fixed. > I'm just not exactly sure about the way to go to get these permissions > in a non-artificial scenario. But I can reproduce it like this: > > - The file xxx has a primary group different from the group which has > permissions, e.g.: > > owner: foo > pgroup: foo_group > > acl: 1 entry > bar_group: full control > > - ls -l xxx > ----rwx---+ 1 foo foo_group 68565 Aug 10 10:37 xxx > > - $ chmod g-w xxx The chmod, if you try to run it, never succeeds. That's the crux of this setup, anything will always have just rwx for the group via ACL and you can't change that. > So, what's going on here and how do we really fix it? It *might* be > prudent to drop any efforts to create DENY ACEs to reflect the POSIX > perms. That results in the documented permission gap between POSIX and > Windows permissions, though. There's just no way to express all possible > POSIX permissions using Windows ALLOW ACEs only. There aren't any deny ACL, you just don't get the right to play with the permissions to start with. FOr Windows it doesn't matter that the owner hasn't got any access rights as long as she's in a group that has. POSIX doesn't even look at the group/ACL if it the owner bits are cleared. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-13 16:33 ` Corinna Vinschen 2015-08-13 17:48 ` Achim Gratz @ 2015-08-13 17:53 ` Corinna Vinschen 2015-08-14 8:30 ` Corinna Vinschen 1 sibling, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-13 17:53 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2181 bytes --] On Aug 13 18:33, Corinna Vinschen wrote: > On Aug 12 20:59, Achim Gratz wrote: > > Corinna Vinschen writes: > > >> I think so, but there are likely some corner cases. But I think that > > >> had been proposed and shot down already, so I was trying to come up with > > >> something less intrusive. > > > > > > This is relatively unintrusive. The current user token is always > > > available. So if owner == current user, for every group in the file's > > > ACL just check if it's in the current user token and, if so, add the > > > perms of that group to the owner perms. > > > > > > Sounds pretty neat as an intermediate solution to me. > > > > I'd play the guinea pig for that snapshot… :-) > > This puzzles me a bit. As example you gave something like > > ----rwx---+ gratz Domain Users [...] foo > > Given the code in recent Cygwin versions, this shouldn't happen if the > user gratz is member of the Domain Users group. The current code > doesn't test all groups in the ACL, only the primary group, but that's > sufficient in most cases. > > So this could only happen if you modify the permissions of windows files > using Cygwin tools and Cygwin helpfully gernerates a DENY ACE for the > owner. > > I'm just not exactly sure about the way to go to get these permissions > in a non-artificial scenario. But I can reproduce it like this: > > - The file xxx has a primary group different from the group which has > permissions, e.g.: > > owner: foo > pgroup: foo_group > > acl: 1 entry > bar_group: full control > > - ls -l xxx > ----rwx---+ 1 foo foo_group 68565 Aug 10 10:37 xxx > > - $ chmod g-w xxx > > - Afterwards, the POSIX-like ACL looks like this: > $ icacls xxx > xxx foo:(DENY)(S,RD,REA,X) > foo:(D,Rc,WDAC,WO,RA,WA) > foo_group:(RX) > Everyone:(Rc,S,RA) > bar_group:(RX) Oh, I get it. This is *because* the current Cygwin doesn't check membership of all groups in the ACL. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-13 17:53 ` Corinna Vinschen @ 2015-08-14 8:30 ` Corinna Vinschen 2015-08-14 10:56 ` Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-14 8:30 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1274 bytes --] On Aug 13 19:53, Corinna Vinschen wrote: > On Aug 13 18:33, Corinna Vinschen wrote: > > On Aug 12 20:59, Achim Gratz wrote: > > > Corinna Vinschen writes: > > > >> I think so, but there are likely some corner cases. But I think that > > > >> had been proposed and shot down already, so I was trying to come up with > > > >> something less intrusive. > > > > > > > > This is relatively unintrusive. The current user token is always > > > > available. So if owner == current user, for every group in the file's > > > > ACL just check if it's in the current user token and, if so, add the > > > > perms of that group to the owner perms. > > > > > > > > Sounds pretty neat as an intermediate solution to me. > > > > > > I'd play the guinea pig for that snapshot… :-) > > > > This puzzles me a bit. As example you gave something like > > [blah] > Oh, I get it. This is *because* the current Cygwin doesn't check > membership of all groups in the ACL. I checked in the change we were talking about. Please give the latest snapshot from https://cygwin.com/snapshots/ a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-14 8:30 ` Corinna Vinschen @ 2015-08-14 10:56 ` Achim Gratz 2015-08-14 13:45 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-14 10:56 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > I checked in the change we were talking about. Please give the latest > snapshot from https://cygwin.com/snapshots/ a try. I've had a quick look and things look good. I'll have to roll out the snapshot to our server and revert the script changes, but it seems like this should solve the problems I've had (and that forced noacl mounts in most cases -- I've kept additional mounts without noacl for testing purposes that will now come in handy). Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-14 10:56 ` Achim Gratz @ 2015-08-14 13:45 ` Corinna Vinschen 2015-08-14 18:25 ` Achim Gratz ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: Corinna Vinschen @ 2015-08-14 13:45 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2057 bytes --] Marco, please see below in terms of L3 cache info. Thanks, On Aug 14 10:56, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > I checked in the change we were talking about. Please give the latest > > snapshot from https://cygwin.com/snapshots/ a try. > > I've had a quick look and things look good. I'll have to roll out the > snapshot to our server and revert the script changes, but it seems like this > should solve the problems I've had (and that forced noacl mounts in most > cases -- I've kept additional mounts without noacl for testing purposes that > will now come in handy). Cool, thanks for your quick feedback. We should just be aware that this is ultimately a kludge. I think I now finally understand what would have to be done to get a generic solution which results in correct POSIX permission evaluation for any current user and any file ACL. However, from some preliminary testing it seems the generic solution has at least two downsides: - It's slow (AuthZ code, setting up and breaking down user/group contexts for each checked file...) - It would always contact the AD when trying to fetch info for AD users, which is bad for remote machines not or slowly connected to the AD server. Anyway, this isn't pressing so it would be nice if you keep on testing. I'm planning to update to 2.2.1 only after a certain pipe problem just discussed on the #cygwin IRC channel is either fixed or settled any other way, Btw., can you please also check /proc/cpuinfo? As discussed, Cygwin's emulation fell short on L3 cache info. I now added code to fetch L3 cache info as well as correct processor topology information on Intel CPUs. For AMD CPUs the topology and cache info was already fine. Linux does not show L3 cache info for AMD CPUs afaics, so I also didn't add that to Cygwin. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-14 13:45 ` Corinna Vinschen @ 2015-08-14 18:25 ` Achim Gratz 2015-08-14 18:43 ` Corinna Vinschen 2015-08-17 8:20 ` Corinna Vinschen 2015-08-15 15:11 ` Achim Gratz 2015-08-15 15:41 ` Marco Atzeri 2 siblings, 2 replies; 40+ messages in thread From: Achim Gratz @ 2015-08-14 18:25 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > Cool, thanks for your quick feedback. Thanks for the snapshot! > We should just be aware that this is ultimately a kludge. I think I now > finally understand what would have to be done to get a generic solution > which results in correct POSIX permission evaluation for any current > user and any file ACL. However, from some preliminary testing it seems > the generic solution has at least two downsides: > > - It's slow (AuthZ code, setting up and breaking down user/group contexts > for each checked file...) > > - It would always contact the AD when trying to fetch info for AD users, > which is bad for remote machines not or slowly connected to the AD server. I think we've came to the same conclusion (modulo the question of whether AuthZ would be usable for this) some time ago. My personal take on this is that the "kludge" is likely better than both what we had before and the result of the pre-snapshot ACL evaluation. If that also solves the problem of denying oneself file access by simply copying a file with carefully crafted ACL, then I would say it's good enough for most circumstances. Probably not good enough to pass the Perl filemode tests during build, but they have some problems in their design anyway. > Anyway, this isn't pressing so it would be nice if you keep on > testing. As I said, I need some time next week to switch things into a mode where problems could potentially show up. I don't expect any, but I don't pretend to understand all the edge cases completely either. > I'm planning to update to 2.2.1 only after a certain pipe problem just > discussed on the #cygwin IRC channel is either fixed or settled any > other way, > > Btw., can you please also check /proc/cpuinfo? Yes, I have both AMD and Intel machines I can test this with. > As discussed, Cygwin's emulation fell short on L3 cache info. I now > added code to fetch L3 cache info as well as correct processor topology > information on Intel CPUs. For AMD CPUs the topology and cache > info was already fine. Linux does not show L3 cache info for AMD CPUs > afaics, so I also didn't add that to Cygwin. I can't test this with a new enough kernel for AMD, but perhaps someone is testing some new iron/OS combination and I can get that information from them. For Intel since some time the L3 cache size is shown (older kernels would show you the per-node L2 cache size IIRC). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-14 18:25 ` Achim Gratz @ 2015-08-14 18:43 ` Corinna Vinschen 2015-08-17 8:20 ` Corinna Vinschen 1 sibling, 0 replies; 40+ messages in thread From: Corinna Vinschen @ 2015-08-14 18:43 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1272 bytes --] On Aug 14 20:25, Achim Gratz wrote: > Corinna Vinschen writes: > > Btw., can you please also check /proc/cpuinfo? > > Yes, I have both AMD and Intel machines I can test this with. > > > As discussed, Cygwin's emulation fell short on L3 cache info. I now > > added code to fetch L3 cache info as well as correct processor topology > > information on Intel CPUs. For AMD CPUs the topology and cache > > info was already fine. Linux does not show L3 cache info for AMD CPUs > > afaics, so I also didn't add that to Cygwin. > > I can't test this with a new enough kernel for AMD, but perhaps someone > is testing some new iron/OS combination and I can get that information > from them. For Intel since some time the L3 cache size is shown (older > kernels would show you the per-node L2 cache size IIRC). Recent kernels as well. I just tested this with a 4.1.4 kernel, and the source code of the upstream master branch shows no changes in terms of the cache info on AMD CPUs. A bit surprising, considering that the L3 cache info is apparently available using the same CPUID leaf. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-14 18:25 ` Achim Gratz 2015-08-14 18:43 ` Corinna Vinschen @ 2015-08-17 8:20 ` Corinna Vinschen 1 sibling, 0 replies; 40+ messages in thread From: Corinna Vinschen @ 2015-08-17 8:20 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1759 bytes --] On Aug 14 20:25, Achim Gratz wrote: > Corinna Vinschen writes: > > Cool, thanks for your quick feedback. > > Thanks for the snapshot! > > > We should just be aware that this is ultimately a kludge. I think I now > > finally understand what would have to be done to get a generic solution > > which results in correct POSIX permission evaluation for any current > > user and any file ACL. However, from some preliminary testing it seems > > the generic solution has at least two downsides: > > > > - It's slow (AuthZ code, setting up and breaking down user/group contexts > > for each checked file...) > > > > - It would always contact the AD when trying to fetch info for AD users, > > which is bad for remote machines not or slowly connected to the AD server. > > I think we've came to the same conclusion (modulo the question of > whether AuthZ would be usable for this) some time ago. My personal take > on this is that the "kludge" is likely better than both what we had > before and the result of the pre-snapshot ACL evaluation. FYI, I revamped my AuthZ tests over the weekend and it's not *that* slow, especially if the application caches and reuses AuthZ user contexts fetched previosly. I have POC code in my local sandbox, and I'm planning to apply this to Cygwin after the 2.2.1 release. I have some hopes that the AuthZ code was the puzzle piece missing in the unified POSIX ACL handling code we tested and then had to drop again earlier this year. Stay tuned for another round of this unified POSIX ACL handling tests later this year. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-14 13:45 ` Corinna Vinschen 2015-08-14 18:25 ` Achim Gratz @ 2015-08-15 15:11 ` Achim Gratz 2015-08-15 18:31 ` Corinna Vinschen 2015-08-17 8:28 ` Achim Gratz 2015-08-15 15:41 ` Marco Atzeri 2 siblings, 2 replies; 40+ messages in thread From: Achim Gratz @ 2015-08-15 15:11 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > Btw., can you please also check /proc/cpuinfo? The output is correct now for a SandyBridge dual-core CPU with logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT. I've also tried to find out why the L3 cache is not reported for AMD in cpuinfo. It seems the reason is that it is logically part of the northbridge system, even if it is on-die and gets reported via CPUID. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-15 15:11 ` Achim Gratz @ 2015-08-15 18:31 ` Corinna Vinschen 2015-08-15 19:04 ` Achim Gratz 2015-08-17 8:28 ` Achim Gratz 1 sibling, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-15 18:31 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 696 bytes --] On Aug 15 17:11, Achim Gratz wrote: > Corinna Vinschen writes: > > Btw., can you please also check /proc/cpuinfo? > > The output is correct now for a SandyBridge dual-core CPU with > logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT. Thanks! > I've also tried to find out why the L3 cache is not reported for AMD in > cpuinfo. It seems the reason is that it is logically part of the > northbridge system, even if it is on-die and gets reported via CPUID. Ok, interesting. Still strange, isn't it? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-15 18:31 ` Corinna Vinschen @ 2015-08-15 19:04 ` Achim Gratz 0 siblings, 0 replies; 40+ messages in thread From: Achim Gratz @ 2015-08-15 19:04 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: >> I've also tried to find out why the L3 cache is not reported for AMD in >> cpuinfo. It seems the reason is that it is logically part of the >> northbridge system, even if it is on-die and gets reported via CPUID. > > Ok, interesting. Still strange, isn't it? In any case, it's not due to an inability to get at the cache sizes. The code that fills those in has the sizes for all levels, but the cache size structure that gets used in /proc/cpuinfo is filled from L2 on AMD and L3 on Intel. If you need the full information on Linux you'd go to /sys/devices/system/cpu or use one of the more specialized programs that give you topology information anyway. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-15 15:11 ` Achim Gratz 2015-08-15 18:31 ` Corinna Vinschen @ 2015-08-17 8:28 ` Achim Gratz 2015-08-17 9:03 ` Corinna Vinschen 1 sibling, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-17 8:28 UTC (permalink / raw) To: cygwin Achim Gratz <Stromeko <at> nexgo.de> writes: > The output is correct now for a SandyBridge dual-core CPU with > logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT. Another IvyBridge dual-core w/ HT looks also correct. However, for the Piledriver Opteron 6328 in the 2012R2 server, Cygwin reports 8 cores. Linux on the other hand would report 8 processors on 4 cores (SMT, like HT on Intel). I don't know where you get the topology information from, but Windows' task manager reports 4 cores with 8 logical processors and two NUMA nodes on this machine. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 8:28 ` Achim Gratz @ 2015-08-17 9:03 ` Corinna Vinschen 2015-08-17 9:12 ` Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-17 9:03 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1860 bytes --] On Aug 17 08:27, Achim Gratz wrote: > Achim Gratz <Stromeko <at> nexgo.de> writes: > > The output is correct now for a SandyBridge dual-core CPU with > > logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT. > > Another IvyBridge dual-core w/ HT looks also correct. > > However, for the Piledriver Opteron 6328 in the 2012R2 server, Cygwin > reports 8 cores. Linux on the other hand would report 8 processors on 4 > cores (SMT, like HT on Intel). I don't know where you get the topology > information from, The code is loosly based on what the Linux kernel does, combined with the information given in http://wiki.osdev.org/Detecting_CPU_Topology_%2880x86%29 So on AMD the topo is taken from cpuids 0x80000008 and 0x00000001, but I may have made a mistake there. [...digging...] Oh, ok. It seems I accidentally dropped a piece of code there. Can you do me a favor and run the following test application? I just need the value your Piledrive CPU returns in ecx returned by cpuid 0x80000008: ======================================================================== #include <stdio.h> #include <stdint.h> static inline void __attribute ((always_inline)) cpuid (uint32_t *a, uint32_t *b, uint32_t *c, uint32_t *d, uint32_t ain, uint32_t cin) { asm volatile ("cpuid" : "=a" (*a), "=b" (*b), "=c" (*c), "=d" (*d) : "a" (ain), "c" (cin)); } int main () { uint32_t eax, ebx, ecx, edx; cpuid (&eax, &ebx, &ecx, &edx, 0x80000008, 0); printf ("0x80000008 %08x %08x %08x %08x\n", eax, ebx, ecx, edx); } ======================================================================== Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 9:03 ` Corinna Vinschen @ 2015-08-17 9:12 ` Achim Gratz 2015-08-17 10:45 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-17 9:12 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > Oh, ok. It seems I accidentally dropped a piece of code there. Can you > do me a favor and run the following test application? I just need the > value your Piledrive CPU returns in ecx returned by cpuid 0x80000008: Opteron 6328 0x80000008 00003030 00000000 00005007 00000000 For reference: i5-3320M 0x80000008 00003024 00000000 00000000 00000000 Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 9:12 ` Achim Gratz @ 2015-08-17 10:45 ` Corinna Vinschen 2015-08-17 10:51 ` Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-17 10:45 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 703 bytes --] On Aug 17 09:12, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > Oh, ok. It seems I accidentally dropped a piece of code there. Can you > > do me a favor and run the following test application? I just need the > > value your Piledrive CPU returns in ecx returned by cpuid 0x80000008: > > Opteron 6328 > 0x80000008 00003030 00000000 00005007 00000000 Thanks. Can you please also show me the output of cpuid 0x8000001e? Looks like newer AMDs provide additional topology info... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 10:45 ` Corinna Vinschen @ 2015-08-17 10:51 ` Achim Gratz 2015-08-17 11:03 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-17 10:51 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > Thanks. Can you please also show me the output of cpuid 0x8000001e? > Looks like newer AMDs provide additional topology info... Opteron 6328 0x80000008 00003030 00000000 00005007 00000000 0x8000001e 00000025 00000102 00000101 00000000 Core i5-3320M 0x80000008 00003024 00000000 00000000 00000000 0x8000001e 00000007 00000340 00000340 00000000 Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 10:51 ` Achim Gratz @ 2015-08-17 11:03 ` Corinna Vinschen 2015-08-17 11:09 ` Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-17 11:03 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 598 bytes --] On Aug 17 10:51, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > Thanks. Can you please also show me the output of cpuid 0x8000001e? > > Looks like newer AMDs provide additional topology info... > > Opteron 6328 > 0x80000008 00003030 00000000 00005007 00000000 > 0x8000001e 00000025 00000102 00000101 00000000 Sorry, forgot one :(. What's the output of cpuid 0x00000001? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 11:03 ` Corinna Vinschen @ 2015-08-17 11:09 ` Achim Gratz 2015-08-17 11:31 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-17 11:09 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > Sorry, forgot one :(. What's the output of cpuid 0x00000001? 0x00000001? I've added 0x80000001 in case that was a typo. Opteron 6328 0x00000001 00600f20 01080800 3e98320b 178bfbff 0x80000001 00600f20 30000000 01ebbfff 2fd3fbff 0x80000008 00003030 00000000 00005007 00000000 0x8000001e 00000021 00000100 00000100 00000000 Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 11:09 ` Achim Gratz @ 2015-08-17 11:31 ` Corinna Vinschen 2015-08-17 11:39 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-17 11:31 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 659 bytes --] On Aug 17 11:08, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > Sorry, forgot one :(. What's the output of cpuid 0x00000001? > > 0x00000001? I've added 0x80000001 in case that was a typo. Heh, no, it wasn't :) > Opteron 6328 > 0x00000001 00600f20 01080800 3e98320b 178bfbff > 0x80000001 00600f20 30000000 01ebbfff 2fd3fbff > 0x80000008 00003030 00000000 00005007 00000000 > 0x8000001e 00000021 00000100 00000100 00000000 Thank you, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 11:31 ` Corinna Vinschen @ 2015-08-17 11:39 ` Corinna Vinschen 2015-08-17 11:43 ` Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-17 11:39 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 786 bytes --] On Aug 17 13:31, Corinna Vinschen wrote: > On Aug 17 11:08, Achim Gratz wrote: > > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > > Sorry, forgot one :(. What's the output of cpuid 0x00000001? > > > > 0x00000001? I've added 0x80000001 in case that was a typo. > > Heh, no, it wasn't :) > > > Opteron 6328 > > 0x00000001 00600f20 01080800 3e98320b 178bfbff > > 0x80000001 00600f20 30000000 01ebbfff 2fd3fbff > > 0x80000008 00003030 00000000 00005007 00000000 > > 0x8000001e 00000021 00000100 00000100 00000000 Uhm... one last question? What's the output of `lscpu'? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 11:39 ` Corinna Vinschen @ 2015-08-17 11:43 ` Achim Gratz 2015-08-17 12:42 ` Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-17 11:43 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > Uhm... one last question? What's the output of `lscpu'? Not available on Cygwin and I don't have access to a Linux box with that processor. I can ask, but it'll take some time. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 11:43 ` Achim Gratz @ 2015-08-17 12:42 ` Achim Gratz 2015-08-17 12:56 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-17 12:42 UTC (permalink / raw) To: cygwin Achim Gratz <Stromeko <at> NexGo.DE> writes: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > Uhm... one last question? What's the output of `lscpu'? > > Not available on Cygwin and I don't have access to a Linux box with that > processor. I can ask, but it'll take some time. No Linux on bare metal with Bulldozer/Piledriver, only an older K10 MagnyCours / Opteron 6174: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 24 On-line CPU(s) list: 0-23 Thread(s) per core: 1 Core(s) per socket: 12 Socket(s): 2 NUMA node(s): 4 Vendor ID: AuthenticAMD CPU family: 16 Model: 9 Stepping: 1 CPU MHz: 2200.091 BogoMIPS: 4400.10 Virtualization: AMD-V L1d cache: 64K L1i cache: 64K L2 cache: 512K L3 cache: 5118K NUMA node0 CPU(s): 0,2,4,6,8,10 NUMA node1 CPU(s): 12,14,16,18,20,22 NUMA node2 CPU(s): 1,3,5,7,9,11 NUMA node3 CPU(s): 13,15,17,19,21,23 I don't have access to that system, so unfortunately I can't run your program. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 12:42 ` Achim Gratz @ 2015-08-17 12:56 ` Corinna Vinschen 2015-08-17 13:12 ` Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-17 12:56 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1942 bytes --] On Aug 17 12:42, Achim Gratz wrote: > Achim Gratz <Stromeko <at> NexGo.DE> writes: > > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > > Uhm... one last question? What's the output of `lscpu'? > > > > Not available on Cygwin and I don't have access to a Linux box with that > > processor. I can ask, but it'll take some time. > > No Linux on bare metal with Bulldozer/Piledriver, only an older K10 > MagnyCours / Opteron 6174: > > Architecture: x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > CPU(s): 24 > On-line CPU(s) list: 0-23 > Thread(s) per core: 1 > Core(s) per socket: 12 > Socket(s): 2 > NUMA node(s): 4 > Vendor ID: AuthenticAMD > CPU family: 16 > Model: 9 > Stepping: 1 > CPU MHz: 2200.091 > BogoMIPS: 4400.10 > Virtualization: AMD-V > L1d cache: 64K > L1i cache: 64K > L2 cache: 512K > L3 cache: 5118K > NUMA node0 CPU(s): 0,2,4,6,8,10 > NUMA node1 CPU(s): 12,14,16,18,20,22 > NUMA node2 CPU(s): 1,3,5,7,9,11 > NUMA node3 CPU(s): 13,15,17,19,21,23 > > I don't have access to that system, so unfortunately I can't run your program. No worries and thank you. I just don't quite understand the stuff returned by 8000001e and what I see above. Do I understand this correctly that a single CPU has 2 NUMA nodes? Does that mean a single HW socket consists of two independent 6 core CPUs? Well, anyway, I just got remote access to a 2 socket systems with Opteron 6386SE CPUs. It's installing rhel7 right now so I might get another clue from there. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 12:56 ` Corinna Vinschen @ 2015-08-17 13:12 ` Achim Gratz 2015-08-17 14:53 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-17 13:12 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > No worries and thank you. I just don't quite understand the stuff > returned by 8000001e and what I see above. Different architectures, so these are not expected to match. > Do I understand this > correctly that a single CPU has 2 NUMA nodes? Does that mean a single > HW socket consists of two independent 6 core CPUs? In the case above, yes. MagnyCours is two Istanbul dies in one package. > Well, anyway, I just got remote access to a 2 socket systems with > Opteron 6386SE CPUs. It's installing rhel7 right now so I might get > another clue from there. Yes, that should help. That's again two dies per package, each with 8 processors paired inside 4 modules. Each of the two die should be more or less identical to the 6328, save for clock frequency. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 13:12 ` Achim Gratz @ 2015-08-17 14:53 ` Corinna Vinschen 2015-08-17 15:47 ` Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2015-08-17 14:53 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1528 bytes --] On Aug 17 13:12, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > > No worries and thank you. I just don't quite understand the stuff > > returned by 8000001e and what I see above. > > Different architectures, so these are not expected to match. Sure, I wasn't expecting that. I referred to the cpuid output you provided and the matching info from your OP starting this subthread. > > Do I understand this > > correctly that a single CPU has 2 NUMA nodes? Does that mean a single > > HW socket consists of two independent 6 core CPUs? > > In the case above, yes. MagnyCours is two Istanbul dies in one package. > > > Well, anyway, I just got remote access to a 2 socket systems with > > Opteron 6386SE CPUs. It's installing rhel7 right now so I might get > > another clue from there. > > Yes, that should help. That's again two dies per package, each with 8 > processors paired inside 4 modules. Each of the two die should be more or > less identical to the 6328, save for clock frequency. Indeed, looking into the output provided by the 6328SE and some 12 core MagnyCours CPU I forgot the number of, was helpful. I *think* I fixed the cpuinfo now for new AMDs which provide 0x800001e topology info. Please give the latest snapshot from https://cygwin.com/snapshots/ a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 14:53 ` Corinna Vinschen @ 2015-08-17 15:47 ` Achim Gratz 2015-08-17 16:11 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2015-08-17 15:47 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > Please give the latest snapshot from https://cygwin.com/snapshots/ > a try. Looks good: 32bit (1001)~ > cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping : 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 1 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping : 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 2 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping : 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 3 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping : 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 4 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping : 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 5 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping : 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 6 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping : 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 7 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping : 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-17 15:47 ` Achim Gratz @ 2015-08-17 16:11 ` Corinna Vinschen 0 siblings, 0 replies; 40+ messages in thread From: Corinna Vinschen @ 2015-08-17 16:11 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1514 bytes --] On Aug 17 15:47, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > Please give the latest snapshot from https://cygwin.com/snapshots/ > > a try. > > Looks good: > 32bit (1001)~ > cat /proc/cpuinfo > processor : 0 > vendor_id : AuthenticAMD > cpu family : 21 > model : 2 > model name : AMD Opteron(tm) Processor 6328 > stepping : 0 > cpu MHz : 3200.000 > cache size : 2048 KB > physical id : 0 > siblings : 8 > core id : 0 > cpu cores : 4 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 13 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt > pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm > sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce > nodeid_msr tbm topoext perfctr_core perfctr_nb > clflush size : 64 > cache_alignment : 64 > address sizes : 48 bits physical, 48 bits virtual > power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro ^^^^^^^^^^^^^^^ And those work too, cool. Thanks for testing, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-14 13:45 ` Corinna Vinschen 2015-08-14 18:25 ` Achim Gratz 2015-08-15 15:11 ` Achim Gratz @ 2015-08-15 15:41 ` Marco Atzeri 2015-08-15 18:32 ` Corinna Vinschen 2 siblings, 1 reply; 40+ messages in thread From: Marco Atzeri @ 2015-08-15 15:41 UTC (permalink / raw) To: cygwin On 14/08/2015 15:45, Corinna Vinschen wrote: > Marco, please see below in terms of L3 cache info. Thanks, > [cut] > > Btw., can you please also check /proc/cpuinfo? > > As discussed, Cygwin's emulation fell short on L3 cache info. I now > added code to fetch L3 cache info as well as correct processor topology > information on Intel CPUs. For AMD CPUs the topology and cache > info was already fine. Linux does not show L3 cache info for AMD CPUs > afaics, so I also didn't add that to Cygwin. > model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz stepping : 9 cpu MHz : 2594.000 cache size : 3072 KB same L3 info as reported by $ hwloc-ls Machine (4383MB total) + NUMANode L#0 (P#0 4383MB) + Package L#0 + L3 L#0 (3072KB) L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 PU L#0 (P#0) PU L#1 (P#1) L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 PU L#2 (P#2) PU L#3 (P#3) > Thanks, > Corinna Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-15 15:41 ` Marco Atzeri @ 2015-08-15 18:32 ` Corinna Vinschen 0 siblings, 0 replies; 40+ messages in thread From: Corinna Vinschen @ 2015-08-15 18:32 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1359 bytes --] On Aug 15 17:41, Marco Atzeri wrote: > On 14/08/2015 15:45, Corinna Vinschen wrote: > >Marco, please see below in terms of L3 cache info. Thanks, > > > [cut] > > > >Btw., can you please also check /proc/cpuinfo? > > > >As discussed, Cygwin's emulation fell short on L3 cache info. I now > >added code to fetch L3 cache info as well as correct processor topology > >information on Intel CPUs. For AMD CPUs the topology and cache > >info was already fine. Linux does not show L3 cache info for AMD CPUs > >afaics, so I also didn't add that to Cygwin. > > > > model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz > stepping : 9 > cpu MHz : 2594.000 > cache size : 3072 KB > > same L3 info as reported by > > $ hwloc-ls > Machine (4383MB total) + NUMANode L#0 (P#0 4383MB) + Package L#0 + L3 L#0 > (3072KB) > L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 > PU L#0 (P#0) > PU L#1 (P#1) > L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 > PU L#2 (P#2) > PU L#3 (P#3) Nice, thanks for testing! Btw., I'm planning to add the sysconf cache output to 2.3.0, now that I know how to do it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Shares with strange ACL settings 2015-08-12 15:58 ` Corinna Vinschen 2015-08-12 18:09 ` Achim Gratz @ 2015-08-13 17:56 ` Achim Gratz 1 sibling, 0 replies; 40+ messages in thread From: Achim Gratz @ 2015-08-13 17:56 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > Cygwin is aware of them and access(2) explicitely checks for them. That > obviously doesn't help for applications like perl, who "know better" > than the underlying OS how to evaluate perms. Just for clarification, Perl doesn't "know better". It's documented that the file test operators only look at the mode bits and naver at the ACL. There's a pragma (use filetest qw/access/; # perldoc filetest) that lets you use access for the tests instead, but it currently is an unloved stepchild that doesn't let you use the stat cache (_) in tests nor stacked file tests (-r -x), which use it. The final nail in the coffin is that with that pragma in effect you can only test filenames, but not file handles. So you really need to write your code from the outset with that pragma in mind since it limits the use of test operators so greatly. At least they left the door open to a future where the filetest pragma does something more sensible on systems that rely to a larger extent on ACL. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2015-08-17 16:11 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-11 8:42 Shares with strange ACL settings Achim Gratz 2015-08-11 17:20 ` Andrey Repin 2015-08-11 17:29 ` Achim Gratz 2015-08-12 15:26 ` Corinna Vinschen 2015-08-12 15:50 ` Achim Gratz 2015-08-12 15:58 ` Corinna Vinschen 2015-08-12 18:09 ` Achim Gratz 2015-08-12 18:32 ` Corinna Vinschen 2015-08-12 21:03 ` Achim Gratz 2015-08-13 16:33 ` Corinna Vinschen 2015-08-13 17:48 ` Achim Gratz 2015-08-13 17:53 ` Corinna Vinschen 2015-08-14 8:30 ` Corinna Vinschen 2015-08-14 10:56 ` Achim Gratz 2015-08-14 13:45 ` Corinna Vinschen 2015-08-14 18:25 ` Achim Gratz 2015-08-14 18:43 ` Corinna Vinschen 2015-08-17 8:20 ` Corinna Vinschen 2015-08-15 15:11 ` Achim Gratz 2015-08-15 18:31 ` Corinna Vinschen 2015-08-15 19:04 ` Achim Gratz 2015-08-17 8:28 ` Achim Gratz 2015-08-17 9:03 ` Corinna Vinschen 2015-08-17 9:12 ` Achim Gratz 2015-08-17 10:45 ` Corinna Vinschen 2015-08-17 10:51 ` Achim Gratz 2015-08-17 11:03 ` Corinna Vinschen 2015-08-17 11:09 ` Achim Gratz 2015-08-17 11:31 ` Corinna Vinschen 2015-08-17 11:39 ` Corinna Vinschen 2015-08-17 11:43 ` Achim Gratz 2015-08-17 12:42 ` Achim Gratz 2015-08-17 12:56 ` Corinna Vinschen 2015-08-17 13:12 ` Achim Gratz 2015-08-17 14:53 ` Corinna Vinschen 2015-08-17 15:47 ` Achim Gratz 2015-08-17 16:11 ` Corinna Vinschen 2015-08-15 15:41 ` Marco Atzeri 2015-08-15 18:32 ` Corinna Vinschen 2015-08-13 17:56 ` Achim Gratz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).