profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/kragniz/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Louis Taylor kragniz Bristol, United Kingdom https://kragniz.eu ミ๏ ω ๏彡 0x8E81A6DAE13E7098

helm/charts 15080

⚠️(OBSOLETE) Curated applications for Kubernetes

kragniz/anyprint 398

Use any* language's print statements in Python

handee/abercompsci-cheatsheets 13

A repo for cheatsheets for Aberystwyth computer science

kragniz/betamax-yaml-serializer 1

YAML serializer for betamax

grand-central-garbage/python3-openttd 0

Pure-python client implementation for the OpenTTD admin network interface.

hmurraydavis/codeacousin 0

Code for a cousin's Christmas Arduino!

issue closedjetstack/cert-manager

Certificate ACME generated by Cert manager not compatible with android 4.2

My company software is running on multiple vending machines using Android 4.2. I noticed that the certificate generated by Cert manager is not compatible with that device. However if I use traefik with ACME the cert works

i'm sure i used "DST Root CA X3" https://letsencrypt.org/docs/certificate-compatibility/#platforms-that-trust-dst-root-ca-x3

Config

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: cloudflare-issuer
spec:
  acme:
    email: {{ .Values.LETENSCRIPT_EMAIL }}
    preferredChain: "DST Root CA X3"
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: cloudflare-issuer
    solvers:
    - dns01:
        cloudflare:
          email: {{ .Values.LETENSCRIPT_EMAIL }}
          apiTokenSecretRef:
            name: cloudflare-api-token-secret
            key: api-token
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: "cloudflare-issuer"
    kubernetes.io/ingress.class: "nginx"
  name: argocd-ingress
  namespace: argocd
spec:
  tls:
  - hosts:
    - {{ .Values.ARGOCD_ADMIN_HOST }}
    secretName: argocd-host-cert
  rules:
  - host: {{ .Values.ARGOCD_ADMIN_HOST }}
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              number: 80

Demo cert domain: test.thuongptit.tech image

kind: Secret
apiVersion: v1
metadata:
  name: argocd-host-cert
  namespace: argocd
data:
  tls.crt: >-
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUZMekNDQkJlZ0F3SUJBZ0lTQS9xNnVIdkJHZXR5dmx6T2U1dkdrMWtpTUEwR0NTcUdTSWIzRFFFQkN3VUEKTURJeEN6QUpCZ05WQkFZVEFsVlRNUll3RkFZRFZRUUtFdzFNWlhRbmN5QkZibU55ZVhCME1Rc3dDUVlEVlFRRApFd0pTTXpBZUZ3MHlNVEExTVRRd01URTFNVEJhRncweU1UQTRNVEl3TVRFMU1UQmFNQjh4SFRBYkJnTlZCQU1UCkZIUmxjM1F1ZEdoMWIyNW5jSFJwZEM1MFpXTm9NSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUIKQ2dLQ0FRRUE1TmNLNSs3cWRMb2FxOXFZYVVEU1ZDMit4Y3lpVitLVitPc2E0a1dHWndxNk83SGM2VndIRW1rTQpPQ3YySHc2ZEpoaHV1ZWhSUm1xTEpQOFVZOGZwN2hJQnloTm52NnlSU2tVZzluWFJaeG1tSk9vc2EyU0JOeVRJCld1M0J1aGFKWVN4S1J1SEpBWndOZlpaZkdQVitUaFVrVXFOblhRN3MwOEpubUtiM3dXbHJWeEFmQVo0V3VHbWkKWUdTejBLR0NEOVdtcFhjWEFoRy9yYkFKVythWGtyV3FxQ3RYR0NUMWtJUXorY0F0em4yY2c1WVY0Y2lRU0s1VApzR1dUN2Z4ai9RRzI5RVlmSHFVRVhSWkxxZStRVmdaaXU4YTVTRnBuYUlVaGgrSGV0MGZJQ0xkR3gyWVVvYi9YCk50bktEL1ErNmJpY0EySjZIVXQ1dnhOMWcwajBPUUlEQVFBQm80SUNVRENDQWt3d0RnWURWUjBQQVFIL0JBUUQKQWdXZ01CMEdBMVVkSlFRV01CUUdDQ3NHQVFVRkJ3TUJCZ2dyQmdFRkJRY0RBakFNQmdOVkhSTUJBZjhFQWpBQQpNQjBHQTFVZERnUVdCQlFpUDQ3UStPNnVNMWNadnJWTjZlMXJEbTFCK3pBZkJnTlZIU01FR0RBV2dCUVVMck1YCnQxaFd5NjVRQ1VEbUg2K2RpeFRDeGpCVkJnZ3JCZ0VGQlFjQkFRUkpNRWN3SVFZSUt3WUJCUVVITUFHR0ZXaDAKZEhBNkx5OXlNeTV2TG14bGJtTnlMbTl5WnpBaUJnZ3JCZ0VGQlFjd0FvWVdhSFIwY0RvdkwzSXpMbWt1YkdWdQpZM0l1YjNKbkx6QWZCZ05WSFJFRUdEQVdnaFIwWlhOMExuUm9kVzl1WjNCMGFYUXVkR1ZqYURCTUJnTlZIU0FFClJUQkRNQWdHQm1lQkRBRUNBVEEzQmdzckJnRUVBWUxmRXdFQkFUQW9NQ1lHQ0NzR0FRVUZCd0lCRmhwb2RIUncKT2k4dlkzQnpMbXhsZEhObGJtTnllWEIwTG05eVp6Q0NBUVVHQ2lzR0FRUUIxbmtDQkFJRWdmWUVnZk1BOFFCMwpBRnpjUTVMKzVxdEZSTEZlbXRSVzVoQTMrOVg2Ujl5aGM1U3lYdWIyeHc3S0FBQUJlV2luL0xVQUFBUURBRWd3ClJnSWhBSU1Ed1JwT25iRG5Qbi9iaGdRbFgwYkVxdzFQQkpOaHdqN0VxT1pzVldUaUFpRUF1bDVMd1k1SW1ESzAKZUpIMzB2aENlVjBTN1N4QW1lTjRPemlPZnduQWw3UUFkZ0QyWEpRdjBYY3dJaFJVR0Fnd2xGYU80MDBUR1RPLwozd3d2SUF2TVR2Rms0d0FBQVhsb3AvMVZBQUFFQXdCSE1FVUNJUUN5UWNiWllCaG5wbzkwQ0N5bnBRWUppOHB0ClR2ZFdnS2VBeTl1NkthcmRRZ0lnQU1LQ1BNSG9MczNTNEwrc0pHbHRuWTNIeCt5WDJzb2c3MlByQ05TTG5ZTXcKRFFZSktvWklodmNOQVFFTEJRQURnZ0VCQUZsaWxVRVVVb3FXOG8vd1pyRlNlYlYxdUxQM2xybzdub2hEdFhnVQplaUE0OFZ3VnFGK1pzL2JVN01rSzl3VE56cGFnMlpvbm5BeEpxWkFVRXZBM3ZKMHo3MHJVYnMybVFHM3NiaUhHCnczRlBUeWNPL1Q1WTdwYzZMNTRWT25mVjh4NWVVSjdnSm1SY0xSaDFhdC85YTg5S1o1U3pXenZnQkR1S2sxMXoKRURra2VSODFhcVhXeUJINGVubjlWRzgzclNPdElZRzlGVEJhbWg2ME1FUUt3U1B0VHpOamh4c3BsVGhJbk1QSwo2SHpLQmJrOUFRMEM2R2p1b3paSHRKU2ZPd29DcFlxRHBjVmJpdks1QlRUZnIrVndIdTJWWlJ3c2JyUmRzWk9MCnBablpzaDBIM3pBMjQ0QURMQ1dGb3R3OHdOVEUvZ1FpZkFCRzJidEZuN3pHVGt3PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLQpNSUlGRmpDQ0F2NmdBd0lCQWdJUkFKRXJDRXJQREJpblUvYldMaVduWDFvd0RRWUpLb1pJaHZjTkFRRUxCUUF3ClR6RUxNQWtHQTFVRUJoTUNWVk14S1RBbkJnTlZCQW9USUVsdWRHVnlibVYwSUZObFkzVnlhWFI1SUZKbGMyVmgKY21Ob0lFZHliM1Z3TVJVd0V3WURWUVFERXd4SlUxSkhJRkp2YjNRZ1dERXdIaGNOTWpBd09UQTBNREF3TURBdwpXaGNOTWpVd09URTFNVFl3TURBd1dqQXlNUXN3Q1FZRFZRUUdFd0pWVXpFV01CUUdBMVVFQ2hNTlRHVjBKM01nClJXNWpjbmx3ZERFTE1Ba0dBMVVFQXhNQ1VqTXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUsKQW9JQkFRQzdBaFVvelBhZ2xOTVBFdXlOVlpMRCtJTHhtYVo2UW9pblhTYXF0U3U1eFV5eHI0NXIrWFhJbzljUApSNVFVVlRWWGpKNm9vamtaOVlJOFFxbE9idlU3d3k3YmpjQ3dYUE5aT09mdHoybndXZ3NidnNDVUpDV0gramR4CnN4UG5IS3pobSsvYjVEdEZVa1dXcWNGVHpqVElVdTYxcnUyUDNtQnc0cVZVcTdadERwZWxRRFJySzlPOFp1dG0KTkh6NmE0dVBWeW1aK0RBWFhicHliL3VCeGEzU2hsZzlGOGZuQ2J2eEsvZUczTUhhY1YzVVJ1UE1yU1hCaUx4ZwpaM1Ztcy9FWTk2SmM1bFAvT29pMlI2WC9FeGpxbUFsM1A1MVQrYzhCNWZXbWNCY1VyMk9rLzVtems1M2NVNmNHCi9raUZIYUZwcmlWMXV4UE1VZ1AxN1ZHaGk5c1ZBZ01CQUFHamdnRUlNSUlCQkRBT0JnTlZIUThCQWY4RUJBTUMKQVlZd0hRWURWUjBsQkJZd0ZBWUlLd1lCQlFVSEF3SUdDQ3NHQVFVRkJ3TUJNQklHQTFVZEV3RUIvd1FJTUFZQgpBZjhDQVFBd0hRWURWUjBPQkJZRUZCUXVzeGUzV0ZiTHJsQUpRT1lmcjUyTEZNTEdNQjhHQTFVZEl3UVlNQmFBCkZIbTBXZVo3dHVYa0FYT0FDSWpJR2xqMjZadHVNRElHQ0NzR0FRVUZCd0VCQkNZd0pEQWlCZ2dyQmdFRkJRY3cKQW9ZV2FIUjBjRG92TDNneExta3ViR1Z1WTNJdWIzSm5MekFuQmdOVkhSOEVJREFlTUJ5Z0dxQVloaFpvZEhSdwpPaTh2ZURFdVl5NXNaVzVqY2k1dmNtY3ZNQ0lHQTFVZElBUWJNQmt3Q0FZR1o0RU1BUUlCTUEwR0N5c0dBUVFCCmd0OFRBUUVCTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFDRnlrNUhQcVAzaFVTRnZOVm5lTEtZWTYxMVRSNlcKUFRObGNsUXRnYURxdyszNElMOWZ6TGR3QUxkdU8vWmVsTjdrSUorbTc0dXlBK2VpdFJZOGtjNjA3VGtDNTN3bAppa2ZtWlc0L1J2VFo4TTZVSys1VXpoSzhqQ2RMdU1HWUw2S3Z6WEdSU2dpM3lMZ2pld1F0Q1BrSVZ6NkQyUVF6CkNrY2hlQW1DSjhNcXlKdTV6bHp5Wk1qQXZubkFUNDV0UkF4ZWtyc3U5NHNRNGVnZFJDbmJXU0R0WTdraCtCSW0KbEpOWG9CMWxCTUVLSXE0UURVT1hvUmdmZnVEZ2hqZTFXckc5TUwrSGJpc3EveUZPR3dYRDlSaVg4RjZzdzZXNAphdkF1dkRzenVlNUwzc3o4NUsrRUM0WS93RlZETnZabzRUWVhhbzZaMGYrbFFLYzB0OERRWXprMU9YVnU4cnAyCnlKTUM2YWxMYkJmT0RBTFp2WUg3bjdkbzFBWmxzNEk5ZDFQNGpua0RyUW94QjNVcVE5aFZsM0xFS1E3M3hGMU8KeUs1R2hERFg4b1ZmR0tGNXUrZGVjSXNINFlhVHc3bVAzR0Z4SlNxdjMrMGxVRkpvaTVMYzVkYTE0OXA5MElkcwpoQ0V4cm9MMSs3bXJ5SWtYUGVGTTVUZ085cjBydlphQkZPdlYyejBncDM1WjArTDRXUGxidUVqTi9seFBGaW4rCkhsVWpyOGdSc0kzcWZKT1FGeS85cktJSlIwWS84T213dC84b1RXZ3kxbWRlSG1tams3ajFuWXN2QzlKU1E2WnYKTWxkbFRUS0IzemhUaFYxK1hXWXA2cmpkNUpXMXpiVldFa0xOeEU3R0pUaEVVRzNzemdCVkdQN3BTV1RVVHNxWApuTFJid0hPb3E3aEh3Zz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUZZRENDQkVpZ0F3SUJBZ0lRUUFGM0lUZlU2VUs0N25hcVBHUUt0ekFOQmdrcWhraUc5dzBCQVFzRkFEQS8KTVNRd0lnWURWUVFLRXh0RWFXZHBkR0ZzSUZOcFoyNWhkSFZ5WlNCVWNuVnpkQ0JEYnk0eEZ6QVZCZ05WQkFNVApEa1JUVkNCU2IyOTBJRU5CSUZnek1CNFhEVEl4TURFeU1ERTVNVFF3TTFvWERUSTBNRGt6TURFNE1UUXdNMW93ClR6RUxNQWtHQTFVRUJoTUNWVk14S1RBbkJnTlZCQW9USUVsdWRHVnlibVYwSUZObFkzVnlhWFI1SUZKbGMyVmgKY21Ob0lFZHliM1Z3TVJVd0V3WURWUVFERXd4SlUxSkhJRkp2YjNRZ1dERXdnZ0lpTUEwR0NTcUdTSWIzRFFFQgpBUVVBQTRJQ0R3QXdnZ0lLQW9JQ0FRQ3Q2Q1J6OUJRMzg1dWVLMWNvSEllKzNMZmZPSkNNYmp6bVY2QjQ5M1hDCm92NzFhbTcyQUU4bzI5NW9obXhFazdheFkvMFVFbXUvSDlMcU1ac2hmdEV6UExwSTlkMTUzN080L3hMeElacEwKd1lxR2NXbEtabVpzajM0OGNMK3RLU0lHOCtUQTVvQ3U0a3VQdDVsK2xBT2YwMGVYZkpsSUkxUG9PSzVQQ20rRApMdEZKVjR5QWRMYmFMOUE0alhzRGNDRWJkZkl3UFBxUHJ0M2FZNnZyRmsvQ2poRkxmczhMNlArMWR5NzBzbnRLCjRFd1NKUXh3alFNcG9PRlRKT3dUMmU0WnZ4Q3pTb3cvaWFOaFVkNnNod2VVOUdOeDdDN2liMXVZZ2VHSlhEUjUKYkhidk81QmllZWJicEpvdkpzWFFFT0VPM3RrUWpoYjd0L2VvOThmbEFnZVlqellJbGVmaU41WU5ObldlK3c1eQpzUjJidkFQNVNRWFlnZDBGdENyV1FlbXNBWGFWQ2cvWTM5VzlFaDgxTHlnWGJOS1l3YWdKWkhkdVJ6ZTZ6cXhaClhtaWRmM0xXaWNVR1FTaytXVDdkSnZVa3lSR25XcU5NUUI5R29abTFwenBSYm9ZN25uMXlweElGZUZudFBsRjQKRlFzRGo0M1FMd1d5UG50S0hFdHpCUkw4eHVyZ1VCTjhRNU4wczhwMDU0NGZBUWpRTU5SYmNUYTBCN3JCTURCYwpTTGVDTzVpbWZXQ0tvcU1wZ3N5NnZZTUVHNktEQTBHaDFnWHhHOEsyOEtoOGhqdEdxRWdxaU54Mm1uYS9IMnFsClBSbVA2emp6Wk43SUt3MEtLUC8zMitJVlF0UWkwQ2RkNFhuK0dPZHdpSzFPNXRtTE9zYmRKMUZ1Lzd4azlUTkQKVHdJREFRQUJvNElCUmpDQ0FVSXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QU9CZ05WSFE4QkFmOEVCQU1DQVFZdwpTd1lJS3dZQkJRVUhBUUVFUHpBOU1Ec0dDQ3NHQVFVRkJ6QUNoaTlvZEhSd09pOHZZWEJ3Y3k1cFpHVnVkSEoxCmMzUXVZMjl0TDNKdmIzUnpMMlJ6ZEhKdmIzUmpZWGd6TG5BM1l6QWZCZ05WSFNNRUdEQVdnQlRFcDdHa2V5eHgKK3R2aFM1QjEvOFFWWUlXSkVEQlVCZ05WSFNBRVRUQkxNQWdHQm1lQkRBRUNBVEEvQmdzckJnRUVBWUxmRXdFQgpBVEF3TUM0R0NDc0dBUVVGQndJQkZpSm9kSFJ3T2k4dlkzQnpMbkp2YjNRdGVERXViR1YwYzJWdVkzSjVjSFF1CmIzSm5NRHdHQTFVZEh3UTFNRE13TWFBdm9DMkdLMmgwZEhBNkx5OWpjbXd1YVdSbGJuUnlkWE4wTG1OdmJTOUUKVTFSU1QwOVVRMEZZTTBOU1RDNWpjbXd3SFFZRFZSME9CQllFRkhtMFdlWjd0dVhrQVhPQUNJaklHbGoyNlp0dQpNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUFLY3dCc2xtNy9EbExRcnQyTTUxb0dyUytvNDQrL3lRb0RGVkRDCjVXeEN1MitiOUxSUHdrU0lDSFhNNndlYkZHSnVlTjdzSjdvNVhQV2lvVzVXbEhBUVU3Rzc1Sy9Rb3NNckFkU1cKOU1VZ05UUDUyR0UyNEhHTnRMaTFxb0pGbGNEeXFTTW81OWFoeTJjSTJxQkRMS29ia3gvSjN2V3JhVjBUOVZ1RwpXQ0xLVFZYa2NHZHR3bGZGUmpsQno0cFlnMWh0bWY1WDZEWU84QTRqcXYySWw5RGpYQTZVU2JXMUZ6WFNMcjlPCmhlOFk0SVdTNndZN2JDa2pDV0RjUlFKTUVoZzc2ZnNPM3R4RStGaVlydXE5UlVXaGlGMW15djRRNlcrQ3lCRkMKRGZ2cDdPT0dBTjZkRU9NNCtxUjlzZGpvU1lLRUJwc3I2R3RQQVF3NGR5NzUzZWM1Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  tls.key: >-
    LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb2dJQkFBS0NBUUVBNU5jSzUrN3FkTG9hcTlxWWFVRFNWQzIreGN5aVYrS1YrT3NhNGtXR1p3cTZPN0hjCjZWd0hFbWtNT0N2Mkh3NmRKaGh1dWVoUlJtcUxKUDhVWThmcDdoSUJ5aE5udjZ5UlNrVWc5blhSWnhtbUpPb3MKYTJTQk55VElXdTNCdWhhSllTeEtSdUhKQVp3TmZaWmZHUFYrVGhVa1VxTm5YUTdzMDhKbm1LYjN3V2xyVnhBZgpBWjRXdUdtaVlHU3owS0dDRDlXbXBYY1hBaEcvcmJBSlcrYVhrcldxcUN0WEdDVDFrSVF6K2NBdHpuMmNnNVlWCjRjaVFTSzVUc0dXVDdmeGovUUcyOUVZZkhxVUVYUlpMcWUrUVZnWml1OGE1U0ZwbmFJVWhoK0hldDBmSUNMZEcKeDJZVW9iL1hOdG5LRC9RKzZiaWNBMko2SFV0NXZ4TjFnMGowT1FJREFRQUJBb0lCQUhIRDZwc1ZicCtyS2JsSQpDajlCUjQ4cjBzeTVCL2hUSUNYSWsrdnJqbjdKbVg0MTFWSjZPdFhQUFpEcllnZGNsNG1wMmRvNGdiZFZIbW05CkdpRGs4UW8zRDRhcmtRZDhQaHJETlRqeHA3SHUwV2RHdCtDSDdhbEJjdzJwWjRjZ3p4bHRFRndld1hRNFpZaUsKNmlvWldicHR6a243REZiNkpZaTgvQTJxN0Q3TlBnNEoyckZneWhwMnBpQlhYZityckR3Vk9SNFp4aEhHNUoxSgo1b1ZHdmRhQWhLM3o4REpla0F0WXFlL2hka29pNlpyVTRROW40S2ZzeVphd1VsK2xXaldqZFVBNHVRbUg1NFQzCk9YeFZ5d1FyOHhOVDBvZnNMQ2IwMUlpQ09yRUlzVFEzUWlXa280ZytlbGNaNDNDS3R6ZjhQTzdMMXFnaGhUSysKclJpZk5iVUNnWUVBK3J2OVIwTm1tTXlkdmZmME9ZMTdQa1kyZE00VlJHR2VkaEdzd2ZsVVNFTit6QmVSaDB1SwpoTXBIbVJ4VGlQT3cwVk5EZlhvQmZWa1M1VHRQOTJqazlWT3NSSkh0UTdpT2doMFdrcHpLVFU3cTBFRFFGOEt0ClQ4bHBDQktIWml2dEg1RWRkdGFOWThaYTVwRlRvTCt5TEVoanlQcHdXbWRGQ0djVHF2SE9hSU1DZ1lFQTZhVlkKQjF0UUNOQTBFMjhwVDV6RDJERHJNSGE0MDJSM3UxSEZ5ZTd3MnpVY0JQbkdPbU8xcmIxOFo0Rk5RcW9uVWZXNgpCYmpwdTNJdlQzamRVQ1dVY1pXZlVJV0VTbFdtbkt6ZFI5U2VIdVJpNmphVTd4TjgzUU02WnIrWFp5bHUxWGVHCngyaVVDallyaVozWWZJRHUzNDlSbUh0VnNrWTB1azRQaGQ2RWU1TUNnWUFaekRQUUhFQTNJbjVzYUZHcGhrUVMKOFRoekppMEwveHRGdktYUXcyMkhqZUpDNzMzYXRNd0l3Nk5BUHFqZG8yMGk3SFU2T001a2JrRENjeXJVSXVmRAowaHNjWndOSmYzaXlMSG9CRmI2KzI0clBhSXZBbGhnczZHVTFIbXJ0K1VFSmlXM0ZwMmVleDI3YzRFRUJmaGUvCjlLYkhxL1RaYUZ5eTg2QVRhNU80THdLQmdFQnVtWFVGNkc5VncxYXNyQTdKWTNUR0lNV3ZwODZjQVN6R0l5NUoKMTJBTUtGcnk2b2lGb0w5MTVzM0FhYWI5dDNReHVJZ0ZjMmQrMks4bzNKZFNsYm94RWNzcDFzNk5DakpndFhFdQpvQ0JTeVRoZnJ2aXpQaGJRNGhVZHRzbjdNaFpxTE4vbTVoUmUxZWpRZjdmdDhuSHlXd1VhMWdvZ3REL0FjU1Z3CnRNWkRBb0dBQ1l3b01Vd2tQUnBKVk5yUlhaclZGMTUrbVU2RDdsMk0xT3VPbFRHeTAxOFFDMGoxaFVTTFAzMkMKOVZPVy9BWEIzMTRacUhPQk9iUTJoQ2FudDdXWEMvazFHNGRBeWlTMW5mdXhQUElaZHNxVWpob2FOUEJiZjlwVgozK0ZSSWlrT0duZ3F1VU1RRTI0WDd2RVU2ZTVVU3JjL29BbXJUcU8xZVRQaTN6T0dGeFE9Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
type: kubernetes.io/tls

Error in android 4.2.2.

Note this is not a browser issue. Our application running on android 4.2.2 has encountered a problem connecting to the server. But when we switched to traefik everything worked again. image

I think the default configurations of Cert manager should be compatible with as many devices as possible.

closed time in 7 hours

nvthuong1996

issue commentjetstack/cert-manager

Certificate ACME generated by Cert manager not compatible with android 4.2

Sorry. I see this is a problem of ssl protocol. https://kubernetes.github.io/ingress-nginx/user-guide/tls/#legacy-tls

nvthuong1996

comment created time in 7 hours

issue commentjetstack/cert-manager

crt.sh is showing certs issued while k8s cluster is showing status as false

@irbekrm, here are the logs during the time that the certs are being issued on crt.sh, and thanks for all the help. log-events-viewer-result.csv

Thanks for the logs! Did you also have a chance to check if the Secret www-wefixlocksnow-com-cert was really not there at that point? In that case, I wonder if it's somehow related to cert-manager failing to create the Secret.

From the logs I just see that cert-manager attempts to re-issue as it does not find the Secret, but the re-issuance fails. If I understand correctly the logs are from around 11pm UTC 10th of May? Looking at crt.sh it appears that there should have been a successful issuance around 10am UTC on that day- so I guess we would need to look at the controller logs from around that point in time, to see why the Secret was not created (if it is the case that the Secret was not there?).

Appreciate that parsing logs of that size is not trivial and I'm sorry you had to go through the downgrade process once again. I have tried to reproduce this issue with cert-manager v1.3.1 with pebble with a few hundred certs with a short renewal time, but did not see anything abnormal during creation or renewal- if you have any suggestions how to reproduce this, do let us know.

I'm kind of surprised that no one else seems to be having these kinds of issues - 14k certs probably isn't the most common use case, but certainly we're not the only ones?

There are users with large cert-manager deployments, 14k won't be the largest, unfortunately we don't have any data as to who is using which versions at the moment. It may be worth to enquire on #cert-manager channel in Kubernetes Slack.

atenciom

comment created time in 10 hours

startedbittner/pyclean

started time in 11 hours

push eventClangBuiltLinux/boot-utils

Nathan Chancellor

commit sha ca59b22fff7d2f916377ad7d1a8b312689ad553a

buildroot: Add support for m68k Signed-off-by: Nathan Chancellor <nathan@kernel.org>

view details

Nathan Chancellor

commit sha 8553f6b9b22f4224c68b264d842a12510ea11889

boot-qemu.sh: Add support for m68k Signed-off-by: Nathan Chancellor <nathan@kernel.org>

view details

Harsh Shandilya

commit sha 5681875a09fbd782001a4b99b35cb49ffa6eae75

Merge pull request #45 from nathanchance/m68k

view details

push time in 13 hours

PR merged ClangBuiltLinux/boot-utils

Reviewers
boot-utils: Add support for m68k

While clang cannot build an m68k kernel yet, this will eventually be needed so why not now? :)

I have verified that this works with GCC 10.3.0 and mac_defconfig. I believe there will eventually be a virt machine too.

+22 -2

0 comment

5 changed files

nathanchance

pr closed time in 13 hours

issue commentjetstack/cert-manager

Certificate Renewal started errors after months

@Nymria could you elaborate a bit on what exactly your issue was?

Nymria

comment created time in 17 hours

issue commentjetstack/cert-manager

challenge in work queue no longer exists

I know this is closed, but if the message is "benign", then it shouldn't really be an error (make it info, or even debug). For operations people, error messages are serious business. Error messages indicate "some action needs to be taken", but if this is just informational, please re-categorize this (and other) messages accordingly.

rnkhouse

comment created time in 17 hours

PR opened ClangBuiltLinux/boot-utils

boot-utils: Add support for m68k

While clang cannot build an m68k kernel yet, this will eventually be needed so why not now? :)

+22 -2

0 comment

5 changed files

pr created time in 17 hours

push eventClangBuiltLinux/misc-scripts

Nathan Chancellor

commit sha 8772641bfb2a0c96c82edd7e2a61ddb943eee250

check-distro-clang.sh: Some fixes 1. Add a trap for Ctrl-C so that the script immediately exits. 2. archlinux/base moved to archlinux/archlinux. 3. Add Debian's oldstable, which is sometimes cared about. 4. Remove ":latest" from the images, as it is implied. 5. Prefix all images with "docker.io/" because some distributions might not ship a containers.conf. Signed-off-by: Nathan Chancellor <nathan@kernel.org>

view details

push time in 21 hours

issue commentClangBuiltLinux/linux

error: relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax

@nickdesaulniers yay :) I can boot 5.13-rc1 on Real hardware now with LLVM=1, so when my patch is accepted, we need to update https://www.kernel.org/doc/html/latest/kbuild/llvm.html#supported-architectures to reflect that RISCV can build with LLVM=1 too

tpimh

comment created time in a day

delete branch ClangBuiltLinux/boot-utils

delete branch : i386

delete time in a day

push eventClangBuiltLinux/continuous-integration2

Nathan Chancellor

commit sha 9ebb07fa14539f40c7bfa4a370ad0e08811a4975

generate_workflow.py: Use unique name for output_artifact We have two TuxSuite jobs, one for defconfigs and one for all*configs, so that we can start testing the defconfigs while the all*configs still build. Even though the TuxSuite jobs happen at the same time, they are usually serial due to the large difference in the number of file being built. However, if a TuxSuite job were to finish before all of the boot testing of the other TuxSuite job was finished, the output_artifact would get overwritten and cause all of the previous jobs to fail. To avoid this race, cache the builds.json under a slightly more descriptive name using the build set name as a suffix. Signed-off-by: Nathan Chancellor <nathan@kernel.org>

view details

Nathan Chancellor

commit sha 04651f7c3fcd2c2de3c6b3add587bf599bed55ff

ci: Regenerate TuxSuite and workflow files Signed-off-by: Nathan Chancellor <nathan@kernel.org>

view details

Nathan Chancellor

commit sha 3f9d0608a9db1562630c73d67e86abe4e36e19fe

Merge pull request #136 from nathanchance/output-name Update artifact upload name

view details

push time in a day

PR merged ClangBuiltLinux/continuous-integration2

Update artifact upload name

As far as I can tell, it is possible for the output_artifacts to get overridden, resulting in builds that cannot be found:

https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/836619133

Normally, defconfigs finish first but it is possible for a cached allmodconfig to beat LTO'd defconfigs. To avoid this race, cache the builds.json under a slightly more descriptive name using the build set name as a suffix.

+465 -465

0 comment

21 changed files

nathanchance

pr closed time in a day

pull request commentbuchgr/bazel-remote

config: Flag to disable access logger

Changes:

  • Change flag from disable_access_logger to access_log_level
  • Add a simple check in validateConfig that a supported log level is supplied
  • Change the logging instantiation business logic to instead discard the output when the level is "none"

I didn't create constants for "none" and "all" since there doesn't seem to be a convention for that (see e.g. "zstd"/"uncompressed") but I can do that if needed.

Additional manual verification:

$ bazelisk run //:bazel-remote -- --dir /tmp/bazel --max_size 1 --port 8080 --access_log_level invalid
...
2021/05/14 18:37:07 bazel-remote built with go1.16.2 from git commit ec16031f6133df98481eb48df8137d1204ba2b63.
'access_log_level' must be set to either "none" or "all"
...
LINKIWI

comment created time in a day

push eventClangBuiltLinux/continuous-integration2

Nathan Chancellor

commit sha e55cc03b2a44e53180c7a964c23a9a1bc9cf14a9

generator.yml: Build arm32 allmodconfig with LLVM_IAS=1 on Android branches with LLVM 13 Commit 44200f2d9b8b ("crypto: arm/curve25519 - Move '.fpu' after '.arch'") landed in 5.10.36, which has been merged into these Android trees and I backported it to android12-5.4: https://android-review.googlesource.com/c/kernel/common/+/1702383 https://android-review.googlesource.com/c/kernel/common/+/1702384 https://android-review.googlesource.com/c/kernel/common/+/1702245 Signed-off-by: Nathan Chancellor <nathan@kernel.org>

view details

Nathan Chancellor

commit sha 830fce255331ecd130f4e7fa921da0e7343550cf

generator.yml: Build arm32 allmodconfig with LLVM_IAS=1 on Android branches with AOSP LLVM Signed-off-by: Nathan Chancellor <nathan@kernel.org>

view details

Nathan Chancellor

commit sha ba205e50e001f666516a82e3a839c10d63adffab

ci: Regenerate TuxSuite and workflow files Signed-off-by: Nathan Chancellor <nathan@kernel.org>

view details

Nathan Chancellor

commit sha 9f14b4d21658d719f33c82742ffaf9bd2b413449

Merge pull request #131 from nathanchance/android-arm-ias Enable LLVM_IAS=1 for Android arm32 allmodconfig with LLVM 13

view details

push time in a day

PR merged ClangBuiltLinux/continuous-integration2

Enable LLVM_IAS=1 for Android arm32 allmodconfig with LLVM 13

Will open for acceptance when this CL has been merged:

https://android-review.googlesource.com/c/kernel/common/+/1702384

+24 -18

0 comment

7 changed files

nathanchance

pr closed time in a day

push eventClangBuiltLinux/continuous-integration2

Nathan Chancellor

commit sha 754fd80abf7c03d89b45afb594dc255dea3489a2

utils.py: Fix crash with LLVM_VERSION=android Traceback (most recent call last): File "./check_logs.py", line 102, in <module> build = get_build() File "/home/runner/work/continuous-integration2/continuous-integration2/utils.py", line 74, in get_build llvm_version = get_requested_llvm_version() File "/home/runner/work/continuous-integration2/continuous-integration2/utils.py", line 64, in get_requested_llvm_version ver = int(os.environ["LLVM_VERSION"]) ValueError: invalid literal for int() with base 10: 'android' Signed-off-by: Nathan Chancellor <nathan@kernel.org>

view details

Nick Desaulniers

commit sha 8370a42c3871aea4c477dbfa52380e1ec759e9e7

Merge pull request #137 from nathanchance/android-clang utils.py: Fix crash with LLVM_VERSION=android

view details

push time in a day

PR merged ClangBuiltLinux/continuous-integration2

utils.py: Fix crash with LLVM_VERSION=android
Traceback (most recent call last):
  File "./check_logs.py", line 102, in <module>
    build = get_build()
  File
"/home/runner/work/continuous-integration2/continuous-integration2/utils.py",
line 74, in get_build
    llvm_version = get_requested_llvm_version()
  File
"/home/runner/work/continuous-integration2/continuous-integration2/utils.py",
line 64, in get_requested_llvm_version
    ver = int(os.environ["LLVM_VERSION"])
ValueError: invalid literal for int() with base 10: 'android'
+3 -3

0 comment

1 changed file

nathanchance

pr closed time in a day

issue commentClangBuiltLinux/linux

AMDGPU general protection fault with LTO

from the initial log:

general protection fault, maybe for address 0xffffb80d81b6b5d8: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:dcn30_update_bw_bounding_box+0x33/0x530 [amdgpu]
RSP: 0018:ffffb80d81b6b5d8 EFLAGS: 00010296

so some bad stack access in dcn30_update_bw_bounding_box perhaps? @aruhier can you provide the output of llvm-objdump -Dr --disassemble-symbols=dcn30_update_bw_bounding_box vmlinux in another file attachment?

Sorry, I'm really not used to tweak with LLVM binaries, so I'm probably not going to be able to adapt too much the commands you give me. So:

llvm-objdump -Dr --disassemble-symbols=dcn30_update_bw_bounding_box vmlinuz-5.12.3-x86_64
vmlinuz-5.12.3-x86_64:	file format coff-x86-64

llvm-objdump: warning: 'vmlinuz-5.12.3-x86_64': failed to disassemble missing symbol dcn30_update_bw_bounding_box

Which is probably not what you want. However I executed it on the amdgpu module: amdgpu.log

aruhier

comment created time in a day

PR opened dynup/kpatch

kpatch-build: enable option -R|--replace to build replace klp

Since 5.1 kernel, klp_patch supports a "replace" option, which does atomic replace of cumulative patches. Enable building such patch with an option.

Signed-off-by: Song Liu song@kernel.org

+36 -1

0 comment

2 changed files

pr created time in a day

issue commentClangBuiltLinux/linux

AMDGPU general protection fault with LTO

Your build command is a little odd:

COMMAND: nice -n15 make -j30 ARCH='x86' AS='/usr/lib/llvm/12/bin/llvm-as' AR='/usr/lib/llvm/12/bin/llvm-ar' CC='/usr/lib/llvm/12/bin/clang' LD='ld.lld' NM='/usr/lib/llvm/12/bin/llvm-nm' OBJCOPY='x86_64-pc-linux-gnu-objcopy' OBJDUMP='x86_64-pc-linux-gnu-objdump' READELF='x86_64-pc-linux-gnu-readelf' STRIP='x86_64-pc-linux-gnu-strip' HOSTAR='x86_64-pc-linux-gnu-ar' HOSTCC='x86_64-pc-linux-gnu-gcc' HOSTCXX='x86_64-pc-linux-gnu-g++' HOSTLD='ld.lld' bzImage

I do not see LLVM_IAS=1 anywhere, which is a little odd, since that is a dependency of HAS_LTO_CLANG. I guess genkernel does not have support for that explicitly but I am guessing you could add LLVM_IAS=1 to your MAKEOPTS. AS='/usr/lib/llvm/12/bin/llvm-as' does not work for selecting the integrated assembler for two reasons:

1. `$(AS)` was removed in commit [aa824e0c962b](https://git.kernel.org/linus/aa824e0c962b532d5073cbb41b2efcd6f5e72bae) ("kbuild: remove AS variable").

2. `llvm-as` converts LLVM IR to LLVM bitcode (`.ll` -> `.bc`), it will not work in this context.

I have no idea if this is actually related to your issue, just a general observation.

It may be worth reporting this to amd-gfx@lists.freedesktop.org to see if anyone else can reproduce it.

cc @samitolvanen

I do, I export LLVM=1 LLVM_IAS=1. Without it, I cannot enable LTO.

aruhier

comment created time in a day

issue commentClangBuiltLinux/linux

error: relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax

that someone is @kraj, who has given talks on Linux and LLVM before. ;)

tpimh

comment created time in a day

issue commentjetstack/cert-manager

crt.sh is showing certs issued while k8s cluster is showing status as false

@irbekrm FYI: I work with @atenciom, and this is the same cluster as the one for #3603, which currently hosts around 14k certs.

We've noticed that once the cluster gets in this state, we get some pretty bad throughput. We had about 5k certs queued, with the following being completed within cert-manager (cert count grouped by status.notAfter date):

   5 2021-08-10
 335 2021-08-08
   4 2021-08-07
   5 2021-08-06
   9 2021-08-05
  20 2021-08-04
  57 2021-08-03
 273 2021-08-02
 232 2021-08-01
  81 2021-07-31
   3 2021-07-29
   1 2021-07-28
  10 2021-07-27

That's 1,035 over a period of 15 days, or roughly 70 per day. Yesterday, we reverted the cluster back to 0.14.3 yesterday to try to get us caught up. It took most of the day to get reverted (remove CRDs, re-create resources, etc), but even with a partial day we had over 300 certs complete. Since then, we've had nearly 2,400 more issued:

2379 2021-08-12
 307 2021-08-11

So, I think that excludes any potential issue with letsencrypt rate limiting, and that there's something odd going on in 1.3.1. I'm kind of surprised that no one else seems to be having these kinds of issues - 14k certs probably isn't the most common use case, but certainly we're not the only ones?

This is in AWS EKS, and we do have the logs in CloudWatch via ContainerInsights going back for months, but they're several hundred GBs of them and distinguished by pod ID, so it's non-trivial to search for the exact ones you're asking for. If you have some kind of filter that we could apply to for search criteria, that would help a lot. Or, if you think having access to the raw logs could be beneficial, please let us know and we can chat about some better ways to share them with you.

atenciom

comment created time in a day

issue closedClangBuiltLinux/linux

Assertion `i == DstIdx || !MI->getOperand(i).isReg() || MI->getOperand(i).getReg() != RegA' failed

This issue is more of an FYI than anything else.

With an assertions build of LLVM 10 and LLVM 11, I get a crash while building x86_64 defconfig:

$ make -skj"$(nproc)" LLVM=1 defconfig kernel/softirq.o
clang-10: /home/nathan/cbl/github/tc-build/llvm-project/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp:1548: void (anonymous namespace)::TwoAddressInstructionPass::processTiedPairs(llvm::MachineInstr *, (anonymous namespace)::TwoAddressInstructionPass::TiedPairList &, unsigned int &): Assertion `i == DstIdx || !MI->getOperand(i).isReg() || MI->getOperand(i).getReg() != RegA' failed.
Stack dump:
0.      Program arguments: /home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10 -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name softirq.c -mrelocation-model static -mthread-model posix -fno-delete-null-pointer-checks -mllvm -warn-stack-size=2048 -mframe-pointer=none -relaxed-aliasing -fmath-errno -fno-rounding-math -masm-verbose -no-integrated-as -mconstructor-aliases -mcode-model kernel -target-cpu x86-64 -target-feature +retpoline-indirect-calls -target-feature +retpoline-indirect-branches -target-feature -sse -target-feature -mmx -target-feature -sse2 -target-feature -3dnow -target-feature -avx -target-feature -x87 -target-feature +retpoline-external-thunk -disable-red-zone -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -nostdsysteminc -nobuiltininc -resource-dir /home/nathan/cbl/usr/stow/llvm/10.0.1/lib/clang/10.0.1 -dependency-file kernel/.softirq.o.d -MT kernel/softirq.o -isystem /home/nathan/cbl/usr/stow/llvm/10.0.1/lib/clang/10.0.1/include -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D KBUILD_MODFILE="kernel/softirq" -D KBUILD_BASENAME="softirq" -D KBUILD_MODNAME="softirq" -D __KBUILD_MODNAME=kmod_softirq -fmacro-prefix-map=./= -O2 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -Werror=unknown-warning-option -Wno-sign-compare -Wno-address-of-packed-member -Wno-format-invalid-specifier -Wno-gnu -Wno-unused-const-variable -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-tautological-constant-out-of-range-compare -std=gnu89 -fno-dwarf-directory-asm -fdebug-compilation-dir /home/nathan/cbl/src/linux -ferror-limit 19 -fmessage-length 0 -fwrapv -stack-protector 2 -mstack-alignment=8 -fcf-protection=none -fwchar-type=short -fno-signed-wchar -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fno-common -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/softirq-0ff896.s -x c kernel/softirq.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'kernel/softirq.c'.
4.      Running pass 'Two-Address instruction pass' on function '@do_softirq'
 #0 0x00000000033bfd7f llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x33bfd7f)
 #1 0x00000000033c025f SignalHandler(int) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x33c025f)
 #2 0x00007f625b3d4960 __restore_rt (/usr/lib/libpthread.so.0+0x13960)
 #3 0x00007f625aec6ef5 raise (/usr/lib/libc.so.6+0x3cef5)
 #4 0x00007f625aeb0862 abort (/usr/lib/libc.so.6+0x26862)
 #5 0x00007f625aeb0747 _nl_load_domain.cold (/usr/lib/libc.so.6+0x26747)
 #6 0x00007f625aebf646 (/usr/lib/libc.so.6+0x35646)
 #7 0x0000000002cafc86 (anonymous namespace)::TwoAddressInstructionPass::runOnMachineFunction(llvm::MachineFunction&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2cafc86)
 #8 0x0000000002a0bfb7 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2a0bfb7)
 #9 0x0000000002dd00a7 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd00a7)
#10 0x0000000002dd0766 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd0766)
#11 0x0000000002dd0b6e llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd0b6e)
#12 0x000000000359b67a clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x359b67a)
#13 0x0000000003d31e6c clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3d31e6c)
#14 0x0000000004593029 clang::ParseAST(clang::Sema&, bool, bool) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x4593029)
#15 0x0000000003c8f9d2 clang::FrontendAction::Execute() (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3c8f9d2)
#16 0x0000000003bc1bf8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3bc1bf8)
#17 0x0000000003d2c348 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3d2c348)
#18 0x0000000001e349fe cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e349fe)
#19 0x0000000001e32b5f ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e32b5f)
#20 0x0000000001e30a0b main (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e30a0b)
#21 0x00007f625aeb1b25 __libc_start_main (/usr/lib/libc.so.6+0x27b25)
#22 0x0000000001e2f86e _start (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e2f86e)
clang-10: error: unable to execute command: Aborted (core dumped)
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)
ClangBuiltLinux clang version 10.0.1 (https://github.com/llvm/llvm-project ef32c611aa214dea855364efd7ba451ec5ec3f74)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/nathan/cbl/usr/stow/llvm/10.0.1/bin

When I bisected Linux, I ended up with https://git.kernel.org/linus/569dd8b4eb7ef666b467c41b8e8e4f2820d07f67 and when I bisected LLVM for the fix, I ended up with https://github.com/llvm/llvm-project/commit/42a82862b625279028130e62846d057425bca691 (ended up in llvmorg-12.0.0), which seems to make sense.

I do not think there is really anything that we can do about this now, other than say do not use assertions with these versions or upgrade your compiler :)

closed time in a day

nathanchance

issue openedClangBuiltLinux/linux

Assertion `i == DstIdx || !MI->getOperand(i).isReg() || MI->getOperand(i).getReg() != RegA' failed

This issue is more of an FYI than anything else.

With an assertions build of LLVM 10 and LLVM 11, I get a crash while building x86_64 defconfig:

$ make -skj"$(nproc)" LLVM=1 defconfig kernel/softirq.o
clang-10: /home/nathan/cbl/github/tc-build/llvm-project/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp:1548: void (anonymous namespace)::TwoAddressInstructionPass::processTiedPairs(llvm::MachineInstr *, (anonymous namespace)::TwoAddressInstructionPass::TiedPairList &, unsigned int &): Assertion `i == DstIdx || !MI->getOperand(i).isReg() || MI->getOperand(i).getReg() != RegA' failed.
Stack dump:
0.      Program arguments: /home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10 -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name softirq.c -mrelocation-model static -mthread-model posix -fno-delete-null-pointer-checks -mllvm -warn-stack-size=2048 -mframe-pointer=none -relaxed-aliasing -fmath-errno -fno-rounding-math -masm-verbose -no-integrated-as -mconstructor-aliases -mcode-model kernel -target-cpu x86-64 -target-feature +retpoline-indirect-calls -target-feature +retpoline-indirect-branches -target-feature -sse -target-feature -mmx -target-feature -sse2 -target-feature -3dnow -target-feature -avx -target-feature -x87 -target-feature +retpoline-external-thunk -disable-red-zone -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -nostdsysteminc -nobuiltininc -resource-dir /home/nathan/cbl/usr/stow/llvm/10.0.1/lib/clang/10.0.1 -dependency-file kernel/.softirq.o.d -MT kernel/softirq.o -isystem /home/nathan/cbl/usr/stow/llvm/10.0.1/lib/clang/10.0.1/include -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D KBUILD_MODFILE="kernel/softirq" -D KBUILD_BASENAME="softirq" -D KBUILD_MODNAME="softirq" -D __KBUILD_MODNAME=kmod_softirq -fmacro-prefix-map=./= -O2 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -Werror=unknown-warning-option -Wno-sign-compare -Wno-address-of-packed-member -Wno-format-invalid-specifier -Wno-gnu -Wno-unused-const-variable -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-tautological-constant-out-of-range-compare -std=gnu89 -fno-dwarf-directory-asm -fdebug-compilation-dir /home/nathan/cbl/src/linux -ferror-limit 19 -fmessage-length 0 -fwrapv -stack-protector 2 -mstack-alignment=8 -fcf-protection=none -fwchar-type=short -fno-signed-wchar -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fno-common -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/softirq-0ff896.s -x c kernel/softirq.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'kernel/softirq.c'.
4.      Running pass 'Two-Address instruction pass' on function '@do_softirq'
 #0 0x00000000033bfd7f llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x33bfd7f)
 #1 0x00000000033c025f SignalHandler(int) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x33c025f)
 #2 0x00007f625b3d4960 __restore_rt (/usr/lib/libpthread.so.0+0x13960)
 #3 0x00007f625aec6ef5 raise (/usr/lib/libc.so.6+0x3cef5)
 #4 0x00007f625aeb0862 abort (/usr/lib/libc.so.6+0x26862)
 #5 0x00007f625aeb0747 _nl_load_domain.cold (/usr/lib/libc.so.6+0x26747)
 #6 0x00007f625aebf646 (/usr/lib/libc.so.6+0x35646)
 #7 0x0000000002cafc86 (anonymous namespace)::TwoAddressInstructionPass::runOnMachineFunction(llvm::MachineFunction&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2cafc86)
 #8 0x0000000002a0bfb7 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2a0bfb7)
 #9 0x0000000002dd00a7 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd00a7)
#10 0x0000000002dd0766 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd0766)
#11 0x0000000002dd0b6e llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd0b6e)
#12 0x000000000359b67a clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x359b67a)
#13 0x0000000003d31e6c clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3d31e6c)
#14 0x0000000004593029 clang::ParseAST(clang::Sema&, bool, bool) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x4593029)
#15 0x0000000003c8f9d2 clang::FrontendAction::Execute() (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3c8f9d2)
#16 0x0000000003bc1bf8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3bc1bf8)
#17 0x0000000003d2c348 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3d2c348)
#18 0x0000000001e349fe cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e349fe)
#19 0x0000000001e32b5f ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e32b5f)
#20 0x0000000001e30a0b main (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e30a0b)
#21 0x00007f625aeb1b25 __libc_start_main (/usr/lib/libc.so.6+0x27b25)
#22 0x0000000001e2f86e _start (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e2f86e)
clang-10: error: unable to execute command: Aborted (core dumped)
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)
ClangBuiltLinux clang version 10.0.1 (https://github.com/llvm/llvm-project ef32c611aa214dea855364efd7ba451ec5ec3f74)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/nathan/cbl/usr/stow/llvm/10.0.1/bin

When I bisected Linux, I ended up with https://git.kernel.org/linus/569dd8b4eb7ef666b467c41b8e8e4f2820d07f67 and when I bisected LLVM for the fix, I ended up with https://github.com/llvm/llvm-project/commit/42a82862b625279028130e62846d057425bca691 (ended up in llvmorg-12.0.0), which seems to make sense.

I do not think there is really anything that we can do about this now, other than say do not use assertions with these versions or upgrade your compiler :)

created time in a day

startedtobetz/LegoMicroscope

started time in a day

issue commentClangBuiltLinux/linux

-Wconstant-conversion in drivers/platform/surface/surface_aggregator_registry.c

Arnd sent a patch: https://lore.kernel.org/r/20210514200453.1542978-1-arnd@kernel.org/

nickdesaulniers

comment created time in a day

issue commentClangBuiltLinux/linux

error: relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax

Someone sent a patch equivalent to mine above: https://lore.kernel.org/r/20210514205643.383422-1-raj.khem@gmail.com/

tpimh

comment created time in a day

issue commentClangBuiltLinux/linux

clang-12: error: unsupported option '-fpatchable-function-entry=8' for target 'riscv64-unknown-linux-gnu'

Fixed: https://git.kernel.org/linus/2c475caf72f37c565c03c2f6b9b9e86ec29932e2

nathanchance

comment created time in a day